[Top][All Lists]

[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`.



# or:
#!/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() {
  case $File in
    /*) ;;
     *) File="$PWD/$File" ;;
  echo -n "$Prefix"; $LS -ld /
  IFS=/; set -- $File; for Component; do IFS=" "
    [ "x" = "x$Component" ] && continue
    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";;
      pathto "$Link" "$Prefix  "

for file; do
  pathto $file ""

reply via email to

[Prev in Thread] Current Thread [Next in Thread]