[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lynx-dev Re: who owns what
From: |
Bela Lubkin |
Subject: |
Re: lynx-dev Re: who owns what |
Date: |
Thu, 8 Oct 1998 19:06:00 -0700 |
Philip Webb wrote:
> 981008 Thomas Dickey wrote:
> > to find out who does own things, you can use 'ls':
> > eg cd / ls -lad . cd /homes ls -lad . cd /homes/purslow ls -lad .
>
> the result of those commands is:
>
> drwxr-xr-x 32 root sys 1024 Sep 30 12:28 .
> drwxr-xr-x 2 root sys 99328 Oct 6 17:24 .
> drwx--x--x 9 purslow user 512 Oct 7 15:36 .
>
> > lxstat(2, "/homes/purslow", {st_mode=S_IFLNK|0755, st_size=18, ...}) = 0
>
> what is lxstat() ? ie is it in Lynx or part of the shell/kernel/what ?
> my reward for laboring at a problem caused -- inadvertently, i know --
> on behalf of people running anonymous sites
> -- see Archive Sep [445 622 769] Aug [11] --
> is to learn more about how UNIX & related software work ...
>
> I (capitalised for once) have no security problem,
> nor do the majority of Lynx users & installers:
> these problems arise ONLY for sites with anonymous users.
No, you are 100% wrong here. The security problem that this code is
trying to avoid arises *ONLY* for NON-anonymous sites.
The problem it's trying to avoid is one where you, a non-anonymous user,
are innocently using Lynx. Some other user on the system, who has a
full shell account, decides to attack you. He places a malicious link
into the directory Lynx is trying to use. When Lynx creates a file in
that directory, it is tricked into following the malicious link, and
overwrites one of your personal files.
This can only happen on systems where the attacker has access to a
shell; such as yours. The person he attacks -- the victim -- could be
anyone running Lynx: another shell user (you), a Lynx-locked non-
anonymous menu account, or a Lynx-locked anonymous account.
The usual case of problems like this would be where Lynx is using /tmp
for temporary files, and especially if /tmp is world-writable and not
sticky. Tom's put in code to try to avoid other instances, such as if
Lynx is using your home directory, but your home directory is
unprotected because its parent is world-writable and not sticky.
In this case it isn't even trying to use Lynx's temp directory
(LYNX_TEMP_SPACE). It's explicitly trying to use your home directory.
I would argue that this shouldn't be checking directory permissions /
status at all. If your home directory is unprotected, you are screwed
no matter what, completely outside of Lynx. Lynx has no business trying
to protect you from that.
And, in this case, Lynx is obviously being fooled by something unusual
about your system's directory structure.
Below is a script, pathto, which will show us the real situation on your
system. It requires either ksh or bash; your SGI system probably has
ksh. It also assumes that `ls -ld file` produces output, for symlinks,
which looks like:
lrwxrwxrwx 1 filbo armory 17 Oct 8 18:08 foo -> bar
`` -> '' sequence between link source ^^^^ target
Show us the output of `pathto $HOME`.
>Bela<
=============================================================================
#!/bin/ksh
# or:
#!/bin/bash
#!/bin/zsh -y
#
# 1997/11/21 pathto 1.0 address@hidden --
# - created
# 1998/10/08 pathto 1.1 address@hidden --
# - work with color ls; bash or zsh as well as ksh
# - handle spaces and `` -> '' in filenames
pathto() {
File="$1"
Prefix="$2"
case $File in
/*) ;;
*) File="$PWD/$File" ;;
esac
Path=
echo -n "$Prefix"; $LS -ld /
IFS=/; set -- $File; for Component; do IFS=" "
[ "x" = "x$Component" ] && continue
Dir="$Path"
Path="$Path/$Component"
Ls=$($LS -ld "$Path")
echo -n "$Prefix"; $LS -ld "$Path"
if [ -L "$Path" ]; then
Link="${Ls#*$Path* -> }" ## assumes `` -> '' in `ls` symlink output
case $Link in
/*) ;;
*) Link="$Dir/$Link";;
esac
pathto "$Link" "$Prefix "
fi
done
}
LS=ls
for file; do
pathto $file ""
done