SunOS 4.1.4 security question
David Staschover
There were security holes in SunOS 4.1.3 sendmail, nfs and ftpd. Have
these problems been fixed in 4.1.4?
Thanks,
David
d...@panix.com
Craig Dewick
>There were security holes in SunOS 4.1.3 sendmail, nfs and ftpd. Have
>these problems been fixed in 4.1.4?
There are some jumbo patches for various pieces of 4.1.4, mainly for nfs and
sendmail. However, rather than install Sun's patches for sendmail and ftpd,
you should replace them with third-party packages.
I have replaced Sun sendmail with BSD sendmail, and Sun ftpd with wu-ftpd on
all of my active machines. Also, you should install Secure Shell to replace
rlogin, rcp and rsh.
Regards,
Craig.
--
Craig Dewick. Send email to 'cde...@lios.apana.org.au'
Point a web browser at 'http://lios.apana.org.au/~cdewick/sun_ark.html' to
access my collection of Sun information and links to other places.
Mark Graff
In article 1...@panix.com, d...@panix.com (David Staschover) writes:
>There were security holes in SunOS 4.1.3 sendmail, nfs and ftpd. Have
>these problems been fixed in 4.1.4?
>
Yes.
-mg-
Mark Graff
Sun Security Coordinator
Chris Evans
On 6 Dec 1996, Mark Graff wrote:
> In article 1...@panix.com, d...@panix.com (David Staschover) writes:
> >There were security holes in SunOS 4.1.3 sendmail, nfs and ftpd. Have
> >these problems been fixed in 4.1.4?
> >
>
> Yes.
So Sun's 'official' position is that 4.1.4 is secure? Chuckle.
Chris.
Mark Graff
I just answered his question. If I had intended to make a broader statement
such as the one you suggested, I would have.
For one thing, such a statement by itself wouldn't mean very much: there are
many valid interpretations of what it means for a system to be secure. For
another, common sense informs me as well as you that UNIX in general, and
SunOS in particular, still harbors serious security holes. In fact I am
one of relatively few people in the world--perhaps you are another; I
have many brothers and sisters here--who has dedicated his life to making
UNIX (and the Net) more secure. (Not "secure"; not yet. Just *more* secure.)
Since I felt the original question was too limited in scope and implied a
misunderstanding of some basic issues, I am also conducting a private email
exchange with the fellow who posted the original question. If you, too,
would like a brief elementary tutorial, let me know; but it's my impression
that most readers of this newsgroup are already as clueful as they want to
be on the topic of SunOS 4.1.4 security patches.
Now I have to get back to work. See you on the Net.
-mg-
d
Thomas H. Ptacek wrote:
> 6 Dec 1996 00:50:57 GMT gr...@Eng.Sun.COM:
> >>There were security holes in SunOS 4.1.3 sendmail, nfs and ftpd. Have
> >>these problems been fixed in 4.1.4?
> ... if you turn off sendmail, nfs, and ftpd - as well as your
> portmapper, every RPC program on the system, and inetd.
Enlighten us to the problems with sunos 4.1.4 ftpd and nfs?
The known nfs bugs are fixed with the jumbo patch. There are
no bugs to ftpd. Sendmail is a writeoff with all OS's. And RPC
and the portmapper have nothing to do with the problems asked about
(aren't proxy nfs stuff fixed?)
> Don't forget find / -name "*" -perm -4000 -exec chmod a-s {} ';'
On every unix.
-- d
Thomas H. Ptacek
6 Dec 1996 00:50:57 GMT gr...@Eng.Sun.COM:
>>There were security holes in SunOS 4.1.3 sendmail, nfs and ftpd. Have
>>these problems been fixed in 4.1.4?
>Yes. [...]
... if you turn off sendmail, nfs, and ftpd - as well as your
portmapper, every RPC program on the system, and inetd.
D'oh! I forgot lpd! D'oh! I forgot X and Openwindows. D'oh!
Don't forget find / -name "*" -perm -4000 -exec chmod a-s {} ';'
--
----------------
Thomas Ptacek at EnterAct, L.L.C., Chicago, IL [tq...@enteract.com]
----------------
exit(main(kfp->kargc, argv, environ));
Thomas H. Ptacek
Fri, 06 Dec 1996 23:45:57 -0800 z...@trouble.org:
>> Don't forget find / -name "*" -perm -4000 -exec chmod a-s {} ';'
Some moreso than others.
Jeff Garzik
Thomas H. Ptacek wrote:
> Don't forget find / -name "*" -perm -4000 -exec chmod a-s {} ';'
...or forget that and remember
find / -name "*" -perm -4000 | xargs chmod a-s
Mr. Ptacek's command executes chmod for every single file find matches.
If you find 1,000 files, chmod is executed 1,000 times. In contrast,
xargs' job is to load up the chmod command line with as many files as
possible before executing it. Be gentle to your Unix system. :)
--
Jeff Garzik Jeff....@spinne.com
Spinne, Inc. http://www.spinne.com/
State-of-the-art efficient systems for the Internet.
d
I wrote:
> There are no bugs to ftpd.
Sorry, I was drinking, but I didn't think I was *drunk*. I'm
virtually certain that there are, just known that I know about,
have been found, published, etc.
-- d
Thomas H. Ptacek
Sat, 07 Dec 1996 03:50:25 -0500 jeff....@spinne.com:
>Mr. Ptacek's command executes chmod for every single file find matches.
>If you find 1,000 files, chmod is executed 1,000 times. In contrast,
>xargs' job is to load up the chmod command line with as many files as
>possible before executing it. Be gentle to your Unix system. :)
If you've enough SUID files to make this a real issue, I'd venture a guess
that you have bigger problems than the load average. =)
D. J. Bernstein
The moment you run that, a local attacker can take over your machine.
Isn't security fun?
---Dan
Put an end to unauthorized mail relaying. http://pobox.com/~djb/qmail.html
Paul Russell
d...@koobera.math.uic.edu (D. J. Bernstein) writes:
>
> Jeff Garzik <jeff....@spinne.com> wrote:
> > find / -name "*" -perm -4000 | xargs chmod a-s
>
> The moment you run that, a local attacker can take over your machine.
>
> Isn't security fun?
Just a sanity check here: directories, full path of chmod, or bogus
args to chmod? The last two aren't a problem with any versions of
find and chmod I can find. Are you referring to /tmp, or what did I
miss?
Seeking enlightenment,
Paul.
--
Paul.R...@RustCorp.com.au "Engineer? So you drive trains?"
Lies, damned lies, and out-of-date documentation.
Currently contracted to Telstra, Sydney.
Paul J. Kinsley
D. J. Bernstein wrote:
>
> Jeff Garzik <jeff....@spinne.com> wrote:
> > find / -name "*" -perm -4000 | xargs chmod a-s
>
> The moment you run that, a local attacker can take over your machine.
>
> Isn't security fun?
>
> Put an end to unauthorized mail relaying. http://pobox.com/~djb/qmail.html
The moment they run that, they may want to hire a local attacker to
fix all the stuff they just broke.
--
- Paul Kinsley | PHONE:800-448-6177 FX:770-442-7525 -
- Dickens Data Systems | URL: http://paulpc.dickens.com -
Bennett Todd
> find / -name "*" -perm -4000 | xargs chmod a-s
Much safer of course to go
find / -name '*' -perm -4000 -print0 | xargs -0 chmod a-s
If your find(1) can't do -print0, or your xargs(1) won't do -0, then get the
GNU findutils <URL:ftp://prep.ai.mit.edu/pub/gnu/findutils-4.1.tar.gz> and
mirrors.
-Bennett
Bruce Barnett
b...@interactive.net (Bennett Todd) writes:
> Much safer of course to go
>
> find / -name '*' -perm -4000 -print0 | xargs -0 chmod a-s
I hope people are capturing the names of the files....
find / -name '*' -perm -4000 -print0 | tee FILES | xargs -0 chmod a-s
Suppose something breaks? Which one of the 100,000 files caused the problem?
--
- Bruce <bar...@crd.ge.com>
D. J. Bernstein
Bennett Todd <b...@interactive.net> wrote:
> Much safer of course to go
> find / -name '*' -perm -4000 -print0 | xargs -0 chmod a-s
That's still devastatingly insecure.
Hint: How does chmod a-s work?
Stefan `Sec` Zehl
In article <1996Dec822....@koobera.math.uic.edu>, D. J. Bernstein wrote:
> Jeff Garzik <jeff....@spinne.com> wrote:
> > find / -name "*" -perm -4000 | xargs chmod a-s
>
> The moment you run that, a local attacker can take over your machine.
'take over' a machine running that command?
The only idea which comes to my mind is, that an attacker would be able
to chmod a-s _any_ file. but you're doing that anyway...
> Isn't security fun?
Please tell me what I'm missing :)
CU,
Sec
--
Jeder Tag an dem du nicht lächelst, ist ein verlorener Tag. (C. Chaplin)
Hiroshima '45 Tsjernobyl '86 Windows '95
Black holes are where GOD is dividing by zero
cyberclay
There must be. I've heard that in every two lines of code there is one
bug. I'm sure that isn't ENTIRELY true...but thats beside the point.
Regards,
cyberclay
-------
Check out cyberclay's Hacked Inhabitants homepage! Many underground
files that are actually HELPFUL! Also information on web site
hosting, and virtual domains (www.you.com). Virtual domains from $25!
www.hacked-inhabitants.com
---
Paul Russell
> > Much safer of course to go
> > find / -name '*' -perm -4000 -print0 | xargs -0 chmod a-s
>
> That's still devastatingly insecure.
>
> Hint: How does chmod a-s work?
Ah. Thanks Dan. The light finally went on.
Gotta love the races,
stanislav shalunov
>>>>> Thus quoth `dan' == D J Bernstein <d...@koobera.math.uic.edu>:
dan> That's still devastatingly insecure.
dan> Hint: How does chmod a-s work?
OK. Not that anyone is going to remove suid and sgid bits from all
files on filesystem, and not that chmod a-s will do it (original poster
must have meant chmod ug-s), and not that this thread has much to do
with actual security, but you are tormenting us. What's insecure in it?
chmod a-s ``doesn't change any permissions,'' at least on SunOS 4, which
is in question. It won't remove suid, sgid, or sticky bits. It does
``nothing.'' It calls lstat() and then chmod() with the same permission
mask that file had. On a system where you can chown files away, one
might copy /bin/sh, create bunch of hard/sym (which doesn't matter
because we call lstat() rather than stat()) links to it, chmod them all
to 4755, and try to exploit race condition arising chowning them to root
and trying to get in between chmod's lstat() and chmod() calls. SunOS
doesn't allow chown'ing away. What is insecure, tell I beg.
dan> http://pobox.com/~djb/qmail.html
By the way: say, sendmail stands for send mail. What does qmail stand
for? Quit using mail? :-)
--
Stanislav Shalunov, http://math.wisc.edu/~shalunov/ | shal...@math.wisc.edu
PGP key fingerprint = 62367EA3D4D01D88E021F40A0D938E12 | public key on www page
Opinions that might have been represented here are just mine, not anyone else's
To err is computer's, to forgive--human.
Bruce Barnett
d...@koobera.math.uic.edu (D. J. Bernstein) writes:
> > Much safer of course to go
> > find / -name '*' -perm -4000 -print0 | xargs -0 chmod a-s
>
> That's still devastatingly insecure.
>
> Hint: How does chmod a-s work?
Call me dense, but I still don't see the problem. I would not do it in
one step, like others have suggested. I'd first list them all, examine
the names of the files, make sure they are all files, do a "ls -l" on
them, capture the previous permissions in case I want to reverse my
actions, and then make the change.
I would also limit it to system files, owned by root, bin, etc.
Since this is not something that has to be done more than once per
system, I see little advantage to making it a one-step process.
Still, I don't see the exact problem.
The Solaris manual says that
> The letter s is only meaningful with u or g,
So chmod u-s might be a better choice.
However, "a-s" works on Solaris 2.5.1. Not sure about the other systems.
Also - if the file is owned by someone else, chmod does not change
ownership of the file.
What am I missing?
--
- Bruce <bar...@crd.ge.com>
Casper H.S. Dik
Bruce Barnett <bar...@crd.ge.com> writes:
>Also - if the file is owned by someone else, chmod does not change
>ownership of the file.
chmod "u-s" file works like this:
lstat(file, &buf);
newmode = buf.st_mode & ~04000;
chmod(file, newmode);
The problem should be obvious now;
make a file mode 4777
between the time chmod stats it do:
rm file
ln -s /etc/passwd file
and /etc/passwd will end up mode 777.
Casper
--
Casper Dik - Sun Microsystems - via my guest account at the University
of Amsterdam. My work e-mail address is: Caspe...@Holland.Sun.COM
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
Bennett Todd
On 11 Dec 1996 17:08:58 +0100, Casper H.S. Dik <cas...@fwi.uva.nl> wrote:
>chmod "u-s" file works like this:
>The problem should be obvious now;
>
> make a file mode 4777
> between the time chmod stats it do:
> rm file
> ln -s /etc/passwd file
Cool! How are you going to sneak a rm and a symlink in between two system
calls being invoked, in pretty rapid succession, from a program being run
interactively, once? You must type even faster than _I_ do!
Seriously, it's always useful to remind people when idioms and programs might
introduce race conditions, but it's also valuable to keep in mind the
difference between theoretical problems and practical ones. In fact, now that
I think about it, given the exact invocation we're discussing:
find / -perm -4000 | xargs chmod u-s
even the potential hole I commented on (-print0/xargs -0) --- files whose
names contain newlines or spaces, confusing xargs --- doesn't have any
practical effect I can see.
So, Dan, was there actually any serious hole, that we haven't seen yet, or
were you just sorta overstating things for dramatic effect?
-Bennett
D. J. Bernstein
Bennett Todd <b...@interactive.net> wrote:
> Cool! How are you going to sneak a rm and a symlink in between two system
> calls being invoked, in pretty rapid succession, from a program being run
> interactively, once?
Easily. Force chmod to trace through a huge chain of directories on a
diferent disk. Make sure to keep the machine busy and the inode cache
flushed.
Bruce Barnett
cas...@fwi.uva.nl (Casper H.S. Dik) writes:
> The problem should be obvious now;
>
> make a file mode 4777
> between the time chmod stats it do:
> rm file
> ln -s /etc/passwd file
>
> and /etc/passwd will end up mode 777.
But isn't that a very small amount of time, that only happens once?
The chances of this working are very slim. After all, the attacker
can't cause the administrator to execute the find command over and
over again.
I suppose the user could create 10,000 files....
And try to time the replacement with symlinks just as the system
administrator executed the find command. But that almost assumes the
attacker knew ahead of time when the command will be executed.
So we have a psychic hacker? :-)
--
- Bruce <bar...@crd.ge.com>
dh...@spams.r.us.com
The find/exec race condition security problems occurs because a file is
accessed twice: once when find does a stat on it, and again when find
execs an external program to further manipulate the file. The situation
is exactly analogous to the race condition when a setuid script is
executed -- the kernel first identifies the interpreter, then executes
it in a separate step.
It's time this class of security holes was closed. I propose that all
system calls be revised where possible to accept an open file descriptor
instead of a filename, and that all utilities be revised to be able to
pass an open file descriptor to an external program.
Then, for example:
find / -perm <whatever> -passfd 3 -exec chmod -3 ug-s \;
In this example, find would always begin by doing an open on each file,
and then would do fstat on the open file descriptor. Now that we have
an open fd to the file all other manipulations should use only this
open fd and not access the file by name. We can of course pass on the
filename to child processes for use in error messages:
find / -perm <whatever> -passfd 3 -exec chmod -3 ug-s -N {} \;
Here chmod takes the argument of -N to be a filename that should be
used in printing error messages.
For efficiency, one might want a combined open + stat system call, that
would return the stat information in a stat structure and also an open
file descriptor as its return value.
/* return file descriptor if open, -1 on error */
fd = statopen(filename, &statbuf, mode);
--
Rahul Dhesi <dh...@spams.r.us.com>
"please ignore Dhesi" -- Mark Crispin <m...@CAC.Washington.EDU>
Roger Espel Llima
In article <1996Dec1118...@koobera.math.uic.edu>,
D. J. Bernstein <d...@koobera.math.uic.edu> wrote:
>Bennett Todd <b...@interactive.net> wrote:
>> Cool! How are you going to sneak a rm and a symlink in between two system
>> calls being invoked, in pretty rapid succession, from a program being run
>> interactively, once?
>
>Easily. Force chmod to trace through a huge chain of directories on a
>diferent disk. Make sure to keep the machine busy and the inode cache
>flushed.
Nicing chmod might help too.
-Roger
--
e-mail: roger.es...@ens.fr
WWW page & PGP key: http://www.eleves.ens.fr:8080/home/espel/index.html
d
Bennett Todd wrote:
> On 11 Dec 1996 17:08:58 +0100, Casper H.S. Dik <cas...@fwi.uva.nl> wrote:
> >chmod "u-s" file works like this:
> >[ lstat ... &~04000 ... chmod ]
> >
> > make a file mode 4777
> > between the time chmod stats it do:
> > rm file
> > ln -s /etc/passwd file
> were you just sorta overstating things for dramatic effect?
The latter. And I thought he was talking about *after* the find
was complete. I'm disappointed. I mean, it's not like you're
going to know when someone actually types something as inane as
that in ;-)
-- d
R. D. Thomas
Ok, I **am** dense. Please explain the problem here.
Paul Russell wrote:
>
> d...@koobera.math.uic.edu (D. J. Bernstein) writes:
> >
> > Bennett Todd <b...@interactive.net> wrote:
> > > Much safer of course to go
> > > find / -name '*' -perm -4000 -print0 | xargs -0 chmod a-s
> >
> > That's still devastatingly insecure.
> >
> > Hint: How does chmod a-s work?
>
> Ah. Thanks Dan. The light finally went on.
>
> Gotta love the races,
> Paul.
> --
> Paul.R...@RustCorp.com.au "Engineer? So you drive trains?"
> Lies, damned lies, and out-of-date documentation.
> Currently contracted to Telstra, Sydney.
--
===========================================================================
|
mailto:r...@kaiwan.com |
===========================================================================
Paul Russell
Bruce Barnett <bar...@crd.ge.com> writes:
>
> d...@koobera.math.uic.edu (D. J. Bernstein) writes:
>
> > > Much safer of course to go
> > > find / -name '*' -perm -4000 -print0 | xargs -0 chmod a-s
> >
> > That's still devastatingly insecure.
> >
> > Hint: How does chmod a-s work?
>
> one step, like others have suggested. I'd first list them all, examine
> the names of the files, make sure they are all files, do a "ls -l" on
> them, capture the previous permissions in case I want to reverse my
> actions, and then make the change.
Non-numeric chmods are not an atomic operation; chmod it does a stat(2)
on the target to figure out the current permissions, then masks out
the bits, then slaps the altered permissions on the target using chmod(2).
There is a gap in here you can exploit. Simply create a dummy file
with permissions 4666, and create a symlink to it. In the gap between
`chmod' doing the stat(2), and doing the chmod(2) (adjacent system
calls under Slowlaris), make the symlink point at (say) /etc/passwd.
Write a script to do this, and run it in different places on the file
system. Chances are one of them will get lucky.
I would have done:
find / -user root -type f -perm -4000 -exec chmod u-s {} \;
This should be safe on any rational implementation of find; one stat
will be done at the start (ie. no race between `-user root' and `-perm
4000', say). Since a user cannot create a setuid file owned by
root[1] in the first place, unless they have write access to a
directory containing such a file (a security flaw already, I expect),
you are safe.
Thankyou Dan, for a stimulating one liner! (And for qmail, of course).
Paul.
[1] On systems that do allow chown by other than root, the setuid bit
is always cleared when chowning, of course.
Casper H.S. Dik - Network Security Engineer
d...@koobera.math.uic.edu (D. J. Bernstein) writes:
>Bennett Todd <b...@interactive.net> wrote:
>> Cool! How are you going to sneak a rm and a symlink in between two system
>> calls being invoked, in pretty rapid succession, from a program being run
>> interactively, once?
>Easily. Force chmod to trace through a huge chain of directories on a
>diferent disk. Make sure to keep the machine busy and the inode cache
>flushed.
Or if you have /net automount maps, you can make it really slow.
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Bennett Todd
On 11 Dec 1996 23:48:47 GMT, Roger Espel Llima <es...@allege.ens.fr> wrote:
>Nicing chmod might help too.
If you are in a position to nice chmod, you already have the privileges of
the invoker --- why are you bothering to attempt to break your own command?
-Bennett
Karl Wiebe
Paul Russell <Paul.R...@rustcorp.com.au> wrote:
[ description of possible subversion via race condition and link ]
>I would have done:
> find / -user root -type f -perm -4000 -exec chmod u-s {} \;
>
>This should be safe on any rational implementation of find; one stat
>will be done at the start (ie. no race between `-user root' and `-perm
>4000', say). Since a user cannot create a setuid file owned by
>root[1] in the first place, unless they have write access to a
>directory containing such a file (a security flaw already, I expect),
>you are safe.
Don't say that! ;^)
For those with their paranoia gain set one notch higher, you have to watch
out for subversion via filename ( e.g. one with " " and ";" characters in it ).
This is the raison d'etre for find2perl.
--Karl
--
== Karl Wiebe == ka...@dnai.com ==
"Order is a form of repetition compulsion" --Freud
"Order is a form of repetition compulsion" --Freud
"Order is a form of repetition compulsion" --Freud
Paul Russell
Karl Wiebe <ka...@dnai.com> writes:
>
> Paul Russell <Paul.R...@rustcorp.com.au> wrote:
> [ description of possible subversion via race condition and link ]
> >I would have done:
> > find / -user root -type f -perm -4000 -exec chmod u-s {} \;
[analysis snipped]
> Don't say that! ;^)
>
> For those with their paranoia gain set one notch higher, you have to watch
> out for subversion via filename ( e.g. one with " " and ";" characters in it ).
> This is the raison d'etre for find2perl.
Shell-like problems to not apply to find's -exec. It doesn't use
`system' or anything silly.
Paul.
Jeff Garzik
d...@koobera.math.uic.edu (D. J. Bernstein) wrote:
> Jeff Garzik <jeff....@spinne.com> wrote:
> > find / -name "*" -perm -4000 | xargs chmod a-s
> The moment you run that, a local attacker can take over your machine.
> Isn't security fun?
For the people who didn't read my article and grasp the
nature of my reply, here's a safer command to run:
find / -name "*" -perm -4000 | xargs echo
The point was to use xargs, and not have find exec a command
for every single match. When you're messing around on a news
server, where you can easily have hundreds of thousands of files
matching a find mask, things like this before become important.
-------------------==== Posted via Deja News ====-----------------------
http://www.dejanews.com/ Search, Read, Post to Usenet
Jonathan Thornburg
[I _think_ I've disentangled the multi-level quoting. If not, my
apologies to any to whom I've misattributed someone else's remarks
or some of whose remarks I've misattributed.]
Jeff Garzik <jeff....@spinne.com> wrote:
> find / -name "*" -perm -4000 | xargs chmod a-s
In article <8510539...@dejanews.com>,
Jeff Garzik <jeff....@spinne.com> wrote:
| For the people who didn't read my article and grasp the
| nature of my reply, here's a safer command to run:
|
| find / -name "*" -perm -4000 | xargs echo
Perhaps I'm just dense this afternoon, but why the -name "*" ?
This appears to be just a time-wasting no-op ... but in fact, it even
looks like a further security risk, as it skips ". files" (which might
be setuid and need fixing).
- Jonathan Thornburg <bk...@island.net> (personal E-mail)
U of British Columbia / Physics Dept / <thor...@theory.physics.ubc.ca>
"The first strike in the American Colonies was in 1776 in Philadelphia,
when [...] carpenters demanded a 72-hour week." -- Anatole Beck