lmb@vsi1.UUCP (Larry Blair) (11/18/88)
It has come to my attention the there is a MAJOR hole created by the way many sites administer their machines. This hole presents an opportunity for ANYONE on the net to do severe damage to your system. For other sites the hole is smaller, but still presents an opportunity for mischief. I will send mail to anyone who is interested. I will ONLY send it to the user "news" at your system. I wish I didn't have to be so cryptic, but I don't want to give anyone ideas. -- Larry Blair ames!vsi1!lmb lmb%vsi1.uucp@ames.arc.nasa.gov
frank@Morgan.COM (Frank Wortner) (11/18/88)
In article <1227@vsi1.UUCP> lmb@vsi1.UUCP (Larry Blair) writes: >It has come to my attention the there is a MAJOR hole created by the way >many sites administer their machines. >[...] >I will send mail to anyone who is interested. I will ONLY send it to the >user "news" at your system. Larry (and anyone else who feels that she/he has found a "MAJOR hole" in the news software), I think you would do us a service if you sent your theory to the maintainer or author of the software involved. Why not drop a note to Rick Adams (rick@seismo.css.gov)? This way, an update can be issued. This would propogate any fix much more effectively and insure that future installations also get the benefit of your change. If you restrict distribution only to those sites that contact you directly, I feel that you are (in effect) guaranteeing that the hole will remain open at most sites. -- Frank "Computers are mistake amplifiers."
honey@mailrus.cc.umich.edu (peter honeyman) (11/19/88)
the major hole has to do with handing certain news articles to sed|sh. this preposterous move is anathema to anyone with a semblance of concern for the integrity of his system. peter
dhesi@bsu-cs.UUCP (Rahul Dhesi) (11/19/88)
In article <800@mailrus.cc.umich.edu> honey@citi.umich.edu (peter honeyman) writes: >the major hole has to do with handing certain news articles to >sed|sh. Are we talking about automatic extraction of UUCP maps? We do it here by first chroot(2)'ing to a small directory tree with just a few tools on it. My code is based on John Quarterman's more complex package. I didn't realize that the danger of piping Usenet postings was a secret. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi
lmb@vsi1.UUCP (Larry Blair) (11/20/88)
In article <117@hudson.Morgan.COM> frank@Morgan.COM (Frank Wortner) writes: >Larry (and anyone else who feels that she/he has found a "MAJOR hole" in >the news software), I think you would do us a service if you sent your >theory to the maintainer or author of the software involved. Why not >drop a note to Rick Adams (rick@seismo.css.gov)? This way, an update >can be issued. This would propogate any fix much more effectively and >insure that future installations also get the benefit of your change. The problem is not necessarily in any particular piece of software. It is an administative problem. >If you restrict distribution only to those sites that contact you directly, >I feel that you are (in effect) guaranteeing that the hole will remain >open at most sites. This, unfortunately, is true. How would you propose distributing the information? To date, I have receive mail from about 1% of the systems on Usenet. This leaves the other 99% vulnerable. The funny thing is that if I were to openly post the problem and solution, I doubt that even 10% of the sites with this problem would fix it. On a different posting: Hey, peter, come on. After all the problems that have occurred just this year, why supply _any_ information to potential net-abusers? -- Larry Blair ames!vsi1!lmb lmb%vsi1.uucp@ames.arc.nasa.gov
clb@loci.UUCP (Charles Brunow) (11/20/88)
In article <800@mailrus.cc.umich.edu>, honey@mailrus.cc.umich.edu (peter honeyman) writes:
+ the major hole has to do with handing certain news articles to
+ sed|sh. this preposterous move is anathema to anyone with a
+ semblance of concern for the integrity of his system.
+
+ peter
Somebody save me the trouble of loading and grep'ing the news
sources ... is this part of the standard news software? While
I sort of understand some people's reluctance to post hole info,
it would save a lot of people a lot of time if there is enough
info to determine who is at risk for any given problem and who
isn't. If everyone is going to have to figure out each problem
for themselves, we're going to have much more cracking knowledge
from sheer necessity.
--
CLBrunow - KA5SOF
clb@loci.uucp, loci@csccat.uucp, loci@killer.dallas.tx.us
Loci Products, POB 833846-131, Richardson, Texas 75083honey@mailrus.cc.umich.edu (peter honeyman) (11/20/88)
Larry Blair writes: >Hey, peter, come on. After all the problems that have occurred just this >year, why supply _any_ information to potential net-abusers? because they'll find out anyway. secrecy is no way to fix bugs. peter
honey@mailrus.cc.umich.edu (peter honeyman) (11/20/88)
Charles Brunow writes: > Somebody save me the trouble of loading and grep'ing the news > sources ... is this part of the standard news software? While > I sort of understand some people's reluctance to post hole info, > it would save a lot of people a lot of time if there is enough > info to determine who is at risk for any given problem and who > isn't. If everyone is going to have to figure out each problem > for themselves, we're going to have much more cracking knowledge > from sheer necessity. what charles said. charles, larry will mail you a description on request, or at least he did for me. (last time, no doubt.) since i'm unaffected by the "bug" (which i would describe as pilot error, not any fundamental weakness), i deleted the message. it has something to do with a program called uuhosts. i don't have uuhosts either. peter
clewis@ecicrl.UUCP (Chris Lewis) (11/21/88)
In article <1227@vsi1.UUCP> lmb@vsi1.UUCP (Larry Blair) writes: >It has come to my attention the there is a MAJOR hole created by the way >many sites administer their machines. This hole presents an opportunity >for ANYONE on the net to do severe damage to your system. For other sites >the hole is smaller, but still presents an opportunity for mischief. >I will send mail to anyone who is interested. I will ONLY send it to the >user "news" at your system. I wish I didn't have to be so cryptic, but I >don't want to give anyone ideas. H'm. I betcha that's the one that I've been hinting about for years. That almost every SA already knows (or *should* know) about. I was composing an article to send on this (with fewer hints), asking how I could get the information out, considering that people don't want security holes posted, the normal people to warn about this already know (eg: Rick, Gene etc.), it's *not* in software that any one person (or group) wrote, lots of people are too lazy to fix it (it's real easy to prevent), and I CAN'T EVEN GET THE DAMNED SECURITY LIST TO SEND ME AN APPLICATION! [Andrew Burt's procedure appears to be refusing to send me an application form - has the NSA told him to not send applications to furriners? ;-}] Anyways, I'm sending mail (from our news account as you've requested) to you about whether it's the same hole. If it's the same one, please post a note to the net saying so (along with e-mail back to me for good measure). If it's not the same hole, I'll post a message similar to yours. I'm *strongly* tempted to send out a harmless exploitation of this hole after giving SA's sufficient warning to get their act together. (I've been dreaming of "neat" ways of using it for years.... ;-) -- Chris Lewis {uunet!attcan,utgpu,yunexus,utzoo}!lsuc!ecicrl!clewis Ferret Mailing list: ...!lsuc!gate!eci386!ferret-request (or lsuc!gate!eci386!clewis or lsuc!clewis)
sl@van-bc.UUCP (pri=-10 Stuart Lynne) (11/21/88)
In article <4833@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >In article <800@mailrus.cc.umich.edu> honey@citi.umich.edu (peter honeyman) >writes: >>the major hole has to do with handing certain news articles to >>sed|sh. >Are we talking about automatic extraction of UUCP maps? We do it here >by first chroot(2)'ing to a small directory tree with just a few tools >on it. My code is based on John Quarterman's more complex package. >I didn't realize that the danger of piping Usenet postings was a >secret. Simpler yet is to use unshar. It's designed to split up shar packages safely. And available in source so you can tune it to your system. Anyone attacking *any* shar file that arrives by news with /bin/sh deserves what they get, even more so if they do it automatically. I've been using it to unpack maps since it was posted. It works well. -- Stuart.Lynne@wimsey.bc.ca {ubc-cs,uunet}!van-bc!sl Vancouver,BC,604-937-7532
clewis@ecicrl.UUCP (Chris Lewis) (11/21/88)
In article <117@hudson.Morgan.COM> frank@Morgan.COM (Frank Wortner) writes: >In article <1227@vsi1.UUCP> lmb@vsi1.UUCP (Larry Blair) writes: >>It has come to my attention the there is a MAJOR hole created by the way >>many sites administer their machines. >Larry (and anyone else who feels that she/he has found a "MAJOR hole" in >the news software), I think you would do us a service if you sent your >theory to the maintainer or author of the software involved. Note that Larry said "by the way many sites administer their machines". Not "there's a hole in some software...". Eg: the holes that Larry and I are talking about are NOT IN ANY DISTRIBUTED SOFTWARE! So, there's nobody to "fix" it... Sigh. -- Chris Lewis {uunet!attcan,utgpu,yunexus,utzoo}!lsuc!ecicrl!clewis Ferret Mailing list: ...!lsuc!gate!eci386!ferret-request (or lsuc!gate!eci386!clewis or lsuc!clewis)
dpw@unisec.usi.com (Darryl P. Wagoner) (11/21/88)
In article <117@hudson.Morgan.COM> frank@Morgan.COM (Frank Wortner) writes: >In article <1227@vsi1.UUCP> lmb@vsi1.UUCP (Larry Blair) writes: >>It has come to my attention the there is a MAJOR hole created by the way >>many sites administer their machines. >>[...] >>I will send mail to anyone who is interested. I will ONLY send it to the >>user "news" at your system. > >Larry (and anyone else who feels that she/he has found a "MAJOR hole" in >the news software), I think you would do us a service if you sent your >theory to the maintainer or author of the software involved. I have gotten mail from Larry about this hole and what he says is true. It is a real hole "created by many sysadmins" not by the usenet software. Therefore it would do little good to inform Rick Adams of the problem except he could fix his system and possibly provide a more secure program. This is what I recommend: Let Larry mail out the problem description to all that request it for the next few weeks and then post the description to the net so that everyone else is made aware of the problem. The problem is easy to fix and/or disable without affecting the usenet software. The bug only allows for the execution of programs run with the news id. -- Darryl Wagoner dpw@unisec.usi.com UniSecure Systems, Inc.; OS/2, Just say No! Round Rock, Tx; (512)-255-8751 (home) (512)-823-3774 UUCP: {cs.utexas!uiucuxc!bigtex!mybest}!unisec!dpw
john@frog.UUCP (John Woods) (11/22/88)
In article <1231@vsi1.UUCP>, lmb@vsi1.UUCP (Larry Blair) writes: > To date, I have receive mail from about 1% of the systems on Usenet. This > leaves the other 99% vulnerable. The funny thing is that if I were to > openly post the problem and solution, I doubt that even 10% of the sites > with this problem would fix it. > Which would mean that 10 times as many sites would be fixed; to look at it from the other side of the coin, a reduction of 10% in the number of vulnerable sites. -- John Woods, Charles River Data Systems, Framingham MA, (617) 626-1101 ...!decvax!frog!john, john@frog.UUCP, ...!mit-eddie!jfw, jfw@eddie.mit.edu Science does not remove the TERROR of the Gods!
tjw@cisunx.UUCP (TJ Wood WA3VQJ) (11/22/88)
In article <1160@unisec.usi.com> dpw@unisec.USI.COM (Darryl P. Wagoner) writes: In article <117@hudson.Morgan.COM> frank@Morgan.COM (Frank Wortner) writes: >In article <1227@vsi1.UUCP> lmb@vsi1.UUCP (Larry Blair) writes: >>It has come to my attention the there is a MAJOR hole created by the way >>many sites administer their machines. >>[...] >>I will send mail to anyone who is interested. I will ONLY send it to the >>user "news" at your system. I've not received the mail as of yet. Could someone please forward it to "news@unix.cis.pittsburgh.edu"? Thanks. Terry -- (UUCP) {decwrl!allegra,bellcore,cadre,psuvax1}!pitt!cisunx!cisvms!tjw (BITNET) TJW@PITTVMS (Internet) tjw%vms.cis.pittsburgh.edu@vb.cc.cmu.edu (CC-Net) CISVMS::TJW
frank@Morgan.COM (Frank Wortner) (11/23/88)
In article <1160@unisec.usi.com> dpw@unisec.usi.com (Darryl P. Wagoner) writes: [ about a hole in Usenet discovered by Larry Blair ] >I have gotten mail from Larry about this hole and what he says is true. >It is a real hole "created by many sysadmins" not by the usenet software. >Therefore it would do little good to inform Rick Adams of the problem >except he could fix his system and possibly provide a more secure program. Since the software comes with documentation, that documentation could be updated to reflect the possibility of a security breach. If the nature of the hole is kept a secret (except to those who read and replied to Larry's original article), both present and future installations will perpetuate it. If knowledge of this hole is spread and documented, it can be closed for good. An undocumented problem is guarranteed to remain. -- Frank "Computers are mistake amplifiers."
lmb@vsi1.UUCP (Larry Blair) (11/23/88)
In article <148@ecicrl.UUCP> clewis@ecicrl.UUCP (Chris Lewis) writes: =In article <1227@vsi1.UUCP> lmb@vsi1.UUCP (Larry Blair) writes: =>It has come to my attention the there is a MAJOR hole created by the way =>many sites administer their machines. = =H'm. I betcha that's the one that I've been hinting about for years. =That almost every SA already knows (or *should* know) about. Given the mail I've received, many were unaware. We must remember that the net is doubling in size every year. =Anyways, I'm sending mail (from our news account as you've requested) to =you about whether it's the same hole. If it's the same one, please post =a note to the net saying so (along with e-mail back to me for good measure). =If it's not the same hole, I'll post a message similar to yours. I received Chris' mail and, like a number of other admins, he has spotted the problem. He even sent me a sample of something that would exploit the problem to give inattentive or unknowledgable admins a warning. =I'm *strongly* tempted to send out a harmless exploitation of this hole =after giving SA's sufficient warning to get their act together. (I've =been dreaming of "neat" ways of using it for years.... ;-) I don't think you should do it. It would put a seal of approval on something we don't want to see. -- Larry Blair ames!vsi1!lmb lmb%vsi1.uucp@ames.arc.nasa.gov
clewis@ecicrl.UUCP (Chris Lewis) (11/24/88)
In article <1961@van-bc.UUCP> sl@van-bc.UUCP (pri=-10 Stuart Lynne) writes: >>In article <800@mailrus.cc.umich.edu> honey@citi.umich.edu (peter honeyman) >>writes: >>>the major hole has to do with handing certain news articles to >>>sed|sh. >Simpler yet is to use unshar. > >It's designed to split up shar packages safely. And available in source so >you can tune it to your system. Er, no. Examine yours very carefully - I haven't seen any version of unshar yet (and I've seen quite a few go by) that does anything more than scan through the file before finding a point where it can start ramming stuff down /bin/sh. Eg: the version written in perl recently posted in comp.sources.misc doesn't do *any* security checking - it simply looks for a "#!" or "cut here" and pipes the rest thru sh. Some security. You know, maybe we should try to invent a new "mailable" archive format that isn't compatible with /bin/sh so that people are *never* tempted into the trap of using sed..|sh or insecure unshars. -- Chris Lewis, Markham, Ontario, Canada {uunet!attcan,utgpu,yunexus,utzoo}!lsuc!ecicrl!clewis Ferret Mailing list: ...!lsuc!gate!eci386!ferret-request (or lsuc!gate!eci386!clewis or lsuc!clewis)
patth@dasys1.UUCP (Patt Haring) (11/24/88)
In article <148@ecicrl.UUCP> clewis@ecicrl.UUCP (Chris Lewis) writes: >In article <1227@vsi1.UUCP> lmb@vsi1.UUCP (Larry Blair) writes: >>It has come to my attention the there is a MAJOR hole created by the way >>many sites administer their machines. This hole presents an opportunity >>for ANYONE on the net to do severe damage to your system. For other sites >>the hole is smaller, but still presents an opportunity for mischief. > >H'm. I betcha that's the one that I've been hinting about for years. >I CAN'T EVEN GET THE DAMNED SECURITY LIST TO SEND ME AN APPLICATION! How 'bout sending the info to the sysops mailing list? ...!uunet!dasys1!sysops sysops@dasys1.UUCP -or- directly to the moderator: rsweeney@dasys1.UUCP Patt Haring {sun!hoptoad,cmcl2!phri}!dasys1!patth -or- uunet!dasys1!patth -or- patth@ccnysci.BITNET Big Electric Cat Public Access Unix (212) 879-9031 - System Operator "To love is to be happy with." -- SONshine
richard@gryphon.COM (Richard Sexton) (11/25/88)
Why am I geting 3 copies of the security list bouncing into my mailbox ?
Excuse me, I have to go try out that new ``ls'' option you guys have
been talking about.
--
Never confuse fruit flies with french frys.
richard@gryphon.COM gryphon!richard gryphon!richard@elroy.jpl.nasa.govsl@van-bc.UUCP (pri=-10 Stuart Lynne) (11/25/88)
In article <151@ecicrl.UUCP> clewis@ecicrl.UUCP (Chris Lewis) writes: >In article <1961@van-bc.UUCP> sl@van-bc.UUCP (pri=-10 Stuart Lynne) writes: >>>In article <800@mailrus.cc.umich.edu> honey@citi.umich.edu (peter honeyman) >>>writes: >>>>the major hole has to do with handing certain news articles to >>>>sed|sh. > >>Simpler yet is to use unshar. >> >>It's designed to split up shar packages safely. And available in source so >>you can tune it to your system. > >Er, no. Examine yours very carefully - I haven't seen any version of >unshar yet (and I've seen quite a few go by) that does >anything more than scan through the file before finding a point where >it can start ramming stuff down /bin/sh. Eg: the version written in Ack! You're right. Almost. There are unshar's available for pc's that do everything themselves. In point of fact that's what I though I was running. Hadn't looked in those directories since '85. I'll dig around in the backup's and see what I can find. Anyone else who has unshar for a pc (as in personal computer, generic, not necessarily ibm) might look at retro-fitting to Unix and posting. It seems to me that when I was Mac'ing I had one running under Aztec C that had come from the Amiga world. It bascially understood a small repoitoire of commands, enough to unpack shar files. It wouldn't be too terribly hard to beef up the security on it to prevent most problems. -- Stuart.Lynne@wimsey.bc.ca {ubc-cs,uunet}!van-bc!sl Vancouver,BC,604-937-7532
peter@ficc.uu.net (Peter da Silva) (11/25/88)
The referenced article suggested switching from shar to some more portable format. Might I suggest the Software Tools Group's text archive format? It's designed for ghastly IBM-style machines with all the limitations of card images, and can be unpacked by hand pretty easily (just look for lines beginning with -h-). I have a copy of the program in ratfor somewhere, and a 'C' conversion would be pretty easy. I suspect that there are 'C' versions around already, though. -- Peter da Silva `-_-' Ferranti International Controls Corporation "Have you hugged U your wolf today?" uunet.uu.net!ficc!peter Disclaimer: My typos are my own damn business. peter@ficc.uu.net
chip@ateng.ateng.com (Chip Salzenberg) (11/26/88)
According to clewis@ecicrl.UUCP (Chris Lewis): >In article <1961@van-bc.UUCP> sl@van-bc.UUCP (pri=-10 Stuart Lynne) writes: >>[Unshar] is designed to split up shar packages safely. >>And available in source so you can tune it to your system. > >Er, no. Er, yes. Rich Salz's "cshar" package includes a "safe" unshar program in C. >You know, maybe we should try to invent a new "mailable" archive format >that isn't compatible with /bin/sh so that people are *never* tempted into >the trap of using sed..|sh or insecure unshars. A good idea, and my next project. -- Chip Salzenberg <chip@ateng.com> or <uunet!ateng!chip> A T Engineering Me? Speak for my company? Surely you jest! Beware of programmers carrying screwdrivers.
pst@comdesign.CDI.COM (Paul Traina) (11/26/88)
mumble. Since the talk about the "hole" has moved on to the point where we're actually talking about it publicly, I'll throw my 2 cents in. Instead of going for an unshar, even a PC version ported to back to UNIX, the proper thing to do is NOT ACCEPT COMMANDS OVER THE NET (oops, I didn't mean to shout... imagine I didn't shout there). Instead, since spaf's map postings all have a standardized format, look for the beginning of data, strip before it, and strip after then end of data (i.e. his signature). Now, the problem with this is that it assumes spaf will always post things using the same format he uses now. I bet, if we say "pretty please", he'll make an effort to keep this sort of format. This seems to be a much more intelligent way of ripping out map data, we probably never would have used shar files (except for the fact that they were around, and they are so bloody useful!). Paul -- Paul Traina pst@condor.cdi.com ...pyramid!comdesign!pst OK, look already, I admit I was wrong! Now don't flame me just because you think I'm a jerk on top of everything else.
nagel@paris.ics.uci.edu (Mark Nagel) (11/26/88)
In article <1988Nov25.174519.13119@ateng.ateng.com>, chip@ateng (Chip Salzenberg) writes: |According to clewis@ecicrl.UUCP (Chris Lewis): |>In article <1961@van-bc.UUCP> sl@van-bc.UUCP (pri=-10 Stuart Lynne) writes: |>>[Unshar] is designed to split up shar packages safely. |>>And available in source so you can tune it to your system. |> |>Er, no. | |Er, yes. Rich Salz's "cshar" package includes a "safe" unshar program in C. Hmm. Please point me at this. I looked through the cshar package and the unshar program just runs /bin/sh on the file. The shell program runs commands, but is by no mean secure (see man page). Which one, then, is secure? Mark Nagel @ UC Irvine, Dept of Info and Comp Sci ARPA: nagel@ics.uci.edu | radiation: n. ... 2. smog with an UUCP: {sdcsvax,ucbvax}!ucivax!nagel | attitude.
spaf@cs.purdue.edu (Gene Spafford) (11/27/88)
In article <572@comdesign.CDI.COM> pst@comdesign.CDI.COM (Paul Traina) writes: >mean to shout... imagine I didn't shout there). Instead, since spaf's >map postings all have a standardized format, ... Ooops! Not me! I used to coordinate the GA/FL maps, but that was over a year ago, and I never posted them. The person coordinating the map postings is Mel Pleasant at Rutgers. He deserves a round of applause for that work (take a bow, Mel). The other people collecting and updating map data also deserve a round of thanks (names taken from the latest README posting): Tohru Asami - asami@kddspeech.kddlabs.jp Piet Beertema - Europe (piet@cwi.nl) Bill Blue - bblue@crash.uucp Haesoon Cho - nmc@sorak.kaist.ac.kr Robert Elz, Dave Davey - map-coord@munnari.UUCP Erik Fair - nca-maps@ucbvax.berkeley.edu Paul Graham - pjg@unrvax.unr.edu David Herron - david@e.ms.uky.edu Nicholas (Nike) Horton - uumap@reed.uucp Hokey - hokey@plus5.com Jeff Janock - nemap@harvard.edu Jeff Lee - jeff@ics.gatech.edu Bob Leffler - bob@rel.eds.com Mikel Manitius - map-request@codas.att.com Doug McCallum - dougm@ico.isc.com Torben Nielson, Bob Cunningham - torben@uhmanoa.UUCP, bob@uhmanoa.UUCP Brian Richter - brianr@rosevax.rosemount.com Rob Robertson - rob@philabs.philips.com Partono Rudiarto - didik@indovax.uucp David Schmidt - davids@iscuva.iscs.com Tim Thompson - tgt@stargate.com Rayan Zachariassen rayan@ai.toronto.edu Dave Zimmerman - dpz@rutgers.edu -- Gene Spafford NSF/Purdue/U of Florida Software Engineering Research Center, Dept. of Computer Sciences, Purdue University, W. Lafayette IN 47907-2004 Internet: spaf@cs.purdue.edu uucp: ...!{decwrl,gatech,ucbvax}!purdue!spaf
df@nud.UUCP (Dale Farnsworth) (11/27/88)
Chris Lewis (clewis@ecicrl.UUCP) writes: > In article <1961@van-bc.UUCP> sl@van-bc.UUCP (pri=-10 Stuart Lynne) writes: > > >Simpler yet is to use unshar. > > Er, no. Examine yours very carefully - I haven't seen any version of > unshar yet (and I've seen quite a few go by) that does > anything more than scan through the file before finding a point where > it can start ramming stuff down /bin/sh. > > Some security. Here is a shell file I've been using to unpack the uucp maps. As long as cat is the only command used in the map files, it ought to work. #! /bin/sh cd $MAPDIR sed -e '1,/^echo/d' -e '/^SHAR_EOF/,$d' | ( read CAT IN TERMINATOR OUT FILENAME if [ "$CAT" != cat -o "$IN" != '<<' -o "$TERMINATOR" != \'SHAR_EOF\' -o "$OUT" != '>' ] then echo "$0: bad shar format." echo "First line after echo is:" echo "$CAT $IN $TERMINATOR $OUT $FILENAME" echo Map file ignored. exit else cat >./$FILENAME fi ) -Dale -- Dale Farnsworth 602-438-3092 noao!asuvax!nud!df
campbell@redsox.UUCP (Larry Campbell) (11/27/88)
What's all this about writing gobs of code to decipher some new shar format? Why not just chroot(2) to a safe place before feeding the article to sh? -- Larry Campbell The Boston Software Works, Inc. campbell@bsw.com 120 Fulton Street wjh12!redsox!campbell Boston, MA 02146
james@bigtex.cactus.org (James Van Artsdalen) (11/27/88)
> You know, maybe we should try to invent a new "mailable" archive format > that isn't compatible with /bin/sh so that people are *never* tempted into > the trap of using sed..|sh or insecure unshars. Wonderful. What a great idea. Doesn't it seem odd that your goal is to create an archive layout that nobody can unpack? How do you ever expect people to unpack this stuff? Are *you* going to ensure that everyone gets a copy of your unpacker, and that vendors all distribute it? John Quaterman's uuhosts package works. It is secure in the sense that a worm or virus cannot propogate (a worm could consume CPU cycles or disk space, but that's about it). Use it. If anyone has a way of breaking chroot(2), I'd like to hear about it... -- James R. Van Artsdalen james@bigtex.cactus.org "Live Free or Die" Home: 512-346-2444 Work: 338-8789 9505 Arboretum Blvd Austin TX 78759
lmb@vsi1.UUCP (Larry Blair) (11/27/88)
I'm getting very tired of dealing with requests for the hole, and it has become a pretty open secret. At the end of this posting is the mail I've been sending out. I received about 300 requests; not very many. A number of the responses bounced, 2 of them because AT&T doesn't know about its own machines. A lot of people thought I was wrong to not just post in the first place. I still think that while it will help some sites, it leaves a lot more more vulnerable. Maybe I'm paranoid, but not as much as the people who said things like, "How do I know that you aren't mailing to 'news' just to exploit some hole and destroy my system?" One thing that bugs the hell out of me: it takes about 30 seconds to create a mail alias, but a lot of supposed administrators sent me mail like, "Gee, we don't have a 'news' user here." -------------------------------------------------------------------------- The hole I have discovered in _many_ systems is the use a script for the automatic unsharing of maps. It would be trivially easy to forge a map entry which contained commands to wreak damage to your system. There is some danger even if you a running "uuhosts". If your script does not do a "chroot" (uuhosts does), you and your network are wide open for anything that can be done by the effective user running the script. You run it as "news"? Can you say "rm -f -r /usr/spool/news"? Uuhosts is only slightly more protected. The mapsh program does a chroot to limit any damage to the directory tree containing the unpacked maps. All of the commands in the effective /bin allow the creation and overwrite of file. The danger here is that, besides overwriting everything in the directory tree including the programs in the /bin, you can run the filesystem out of space or out of inodes. And since mapsh runs as root, out of space means REALLY out of space. Planting Trojan Horses is also possible. Solution: Do not execute the map script. Write your own script to unpack it. -- Larry Blair ames!vsi1!lmb lmb%vsi1.uucp@ames.arc.nasa.gov
jbuck@epimass.EPI.COM (Joe Buck) (11/27/88)
In article <561@redsox.UUCP> campbell@redsox.UUCP (Larry Campbell) writes: >What's all this about writing gobs of code to decipher some new shar format? >Why not just chroot(2) to a safe place before feeding the article to sh? The existing "uuhosts" program does this, and that's how I unpack the maps. It is setuid root, but reverts to the real id immediately after the chroot(2) call, so all it can do is write to the map directory; it cannot overwrite the copy of "sh" or "sed" in the map directory unless root runs uuhosts (so don't have root run uuhosts!). It is possible for a phony script to fill up the filesystem or overwrite the maps, but that's a risk I'm willing to take (as opposed to reading through 4Mb of map postings a month to make sure they are safe). Given that "uuhosts" can be obtained from comp.sources.* archive sites, if you're worried, run it! -- - Joe Buck jbuck@epimass.epi.com, or uunet!epimass.epi.com!jbuck, or jbuck%epimass.epi.com@uunet.uu.net for old Arpa sites Every day is a renewal, every morning the daily miracle... This joy you feel is life. - Gertrude Stein
bill@twwells.uucp (T. William Wells) (11/27/88)
In article <561@redsox.UUCP> campbell@redsox.UUCP (Larry Campbell) writes:
: What's all this about writing gobs of code to decipher some new shar format?
: Why not just chroot(2) to a safe place before feeding the article to sh?
Because you have to be superuser to chroot. I'm not about to have
chroot(1) be setuid root, so that means writing a special setuid root
program that just chroots so I can then unshar my mail maps. And that
means having One More setuid root program running around on my system.
No thanks.
---
Bill
{uunet|novavax}!proxftl!twwells!billdww@stl.stc.co.uk (David Wright) (11/27/88)
In article <1227@vsi1.UUCP> lmb@vsi1.UUCP (Larry Blair) writes:
#It has come to my attention the there is a MAJOR hole (in news)
#Larry Blair ames!vsi1!lmb lmb%vsi1.uucp@ames.arc.nasa.gov
In a later article Larry notes that only 1% of sites have mailed him to
ask about it. I wonder how many have actually done so, but not got
to him? I've tried 3 times now: once to lmb@vsi1.uucp, once to the
address in his sig (via ames), and once to an address made out of his Path
converted to % form. All three bounced from either ames or from altnet
with 'bad system name', e.g.
From uucp@altnet.uucp Sat Nov 26 17:09:53 1988
Message-Id: <8811250354.AA04728@altnet.ALTOS.COM>
======= command failed =======
COMMAND: /usr/bin/uux -auunet!mcvax!stl.stc.co.uk!dww -r - vsi1!rmail '(lmb)'
======= standard error follows =======
bad system name: vsi1
uux failed ( 11 )
So is there a problem in getting mail to Larry, or what?
Larry, if you read this please send your warning to news@stl.stc.co.uk
and also check whether there are problems with mail to your site.
I'll copy it on to the UK security list if you like (the 'world' one being
strangely silent since the message saying it would restart soon). Thanks.
--
Regards, "Are you sure YOUR password won't appear in RTM's next list?"
David Wright STL, London Road, Harlow, Essex CM17 9NA, UK
dww@stl.stc.co.uk <or> ...uunet!mcvax!ukc!stl!dww <or> PSI%234237100122::DWWrick@pcrat.UUCP (Rick Richardson) (11/27/88)
In article <2301@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >The referenced article suggested switching from shar to some more portable >format. > >Might I suggest the Software Tools Group's text archive format? It's designed IF a new format is being proposed as a standard, please make sure that it can easily handle the odd bits of binary stuff that are needed by many programs. Just handling the text is not enough. I'm not talking about executables, I'm talking about, say, icon bitmaps and the like. I want to say: portarc * And have the files packed up, even if some are binary. And I don't want to have to say which ones are binary! Also, the format should allow browsing at least the first few files without having to unpack it. (Without this requirement, we might as well be shipping around compressed and uuencoded "tar", "cpio -c", or "afio" archives). -- Rick Richardson | JetRoff "di"-troff to LaserJet Postprocessor|uunet!pcrat!dry2 PC Research,Inc.| Mail: uunet!pcrat!jetroff; For anon uucp do:|for Dhrystone 2 uunet!pcrat!rick| uucp jetroff!~jetuucp/file_list ~nuucp/. |submission forms. jetroff Wk2200-0300,Sa,Su ACU {2400,PEP} 12013898963 "" \d\r\d ogin: jetuucp
blm@cxsea.UUCP (Brian Matthews) (11/28/88)
Dale Farnsworth (df@nud.UUCP) writes: |#! /bin/sh |cd $MAPDIR [...] | read CAT IN TERMINATOR OUT FILENAME | if [ "$CAT" != cat -o "$IN" != '<<' -o "$TERMINATOR" != \'SHAR_EOF\' -o "$OUT" != '>' ] | then [...] | else | cat >./$FILENAME What if filename is ../../../../../../../../../etc/passwd, or ../../../../../../../../../../usr/lib/news/active, or ... Whoops. -- Brian L. Matthews blm@cxsea.UUCP ...{mnetor,uw-beaver!ssc-vax}!cxsea!blm +1 206 251 6811 Computer X Inc. - a division of Motorola New Enterprises
patg@impch.UUCP (Patrick Guelat) (11/28/88)
In article <800@mailrus.cc.umich.edu> honey@citi.umich.edu (p. honeyman) writes:
% the major hole has to do with handing certain news articles to
% sed|sh. this preposterous move is anathema to anyone with a
% semblance of concern for the integrity of his system.
%
% peter
If we're talking about the same hole, it's easy to fix it..
I discovered it about one year ago. The Problem is, that rnews/inews
executes some shellscripts.....
So go and edit all this scripts and set this damned 'IFS' and 'PATH' to
correct values !!
Another hint: Don't make rnews executable for everyone....
Patrick
--
\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//
// Patrick Guelat, patg@impch ..!altger!impch!{boxdiger,patrick,patg} \\
\\ "LOVE DOESN'T MAKE THE WORLD GO AROUND, JUST UP AND DOWN A BIT !!!" //
//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\//\\lmb@vsi1.UUCP (Larry Blair) (11/28/88)
in article <2675@epimass.EPI.COM> jbuck@epimass.EPI.COM (Joe Buck) writes:
=It is possible for a phony script to fill up the filesystem or
=overwrite the maps, but that's a risk I'm willing to take (as opposed
=to reading through 4Mb of map postings a month to make sure they are
=safe). Given that "uuhosts" can be obtained from comp.sources.*
=archive sites, if you're worried, run it!
I disagree with Joe entirely. Running out of inodes does some really nasty
things to your system, and that's one of the easiest things to make happen.
Why execute the map script when uuhosts can easily be modified to unpack them
with a script?
--
Larry Blair ames!vsi1!lmb lmb%vsi1.uucp@ames.arc.nasa.govpeter@ficc.uu.net (Peter da Silva) (11/28/88)
In article <624@pcrat.UUCP>, rick@pcrat.UUCP (Rick Richardson) writes: > In article <2301@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: > >The referenced article suggested switching from shar to some more portable > >format. > >Might I suggest the Software Tools Group's text archive format? It's designed > IF a new format is being proposed as a standard, please > make sure that it can easily handle the odd bits of binary > stuff that are needed by many programs. UUencode them before adding them to the archive. Write a program that wraps around 'ar' and does this... you know, a tools-based approach. > Also, the format should allow browsing at least the first > few files without having to unpack it. The software tools format gives you this... it's purely textual. It's very easy to crack open, too. For example, "grep '^-h-'" gives you an index. -- Peter da Silva `-_-' Ferranti International Controls Corporation "Have you hugged U your wolf today?" uunet.uu.net!ficc!peter Disclaimer: My typos are my own damn business. peter@ficc.uu.net
jack@swlabs.UUCP (Jack Bonn) (11/28/88)
In article <1250@vsi1.UUCP> lmb@vsi1.UUCP (Larry Blair) writes: >Why execute the map script when uuhosts can easily be modified to unpack them >with a script? I run the following script daily to keep my map data base up to date. It has the following features: 1) It doesn't give the map entry directly to sh (good for security). 2) It allows the normal expire/supersedes logic to keep old maps out of the data base (good for disk space management). 3) It uses pipes for intermediate results (good for concurrency as well as piece of mind). Here it is: PATH=$PATH:$HOME/bin export PATH for file in /usr/spool/news/comp/mail/maps/* do sed '1,/cat.*SHAR_EOF/d /SHAR_EOF/,$d' <$file done | pathalias -dihnp4 | pathproc >/usr/tmp/newpaths mv $HOME/paths $HOME/opaths mv /usr/tmp/newpaths $HOME/paths But I still have to unmount and fsck the partition containing news to keep from running out of inodes. :-( At least I do it from cron. -- Jack Bonn, <> Software Labs, Ltd, Box 451, Easton CT 06612 uunet!swlabs!jack (UUCP) jack%swlabs.uucp@uunet.uu.net (INTERNET)
waters@dover.uucp (Mike Waters) (11/28/88)
In article <1247@vsi1.UUCP> lmb@vsi1.UUCP (Larry Blair) writes: > >One thing that bugs the hell out of me: it takes about 30 seconds to create >a mail alias, but a lot of supposed administrators sent me mail like, "Gee, >we don't have a 'news' user here." It may suprise you to know that many of us find that to be a significant chore! Typing the "magic words" is about 30 seconds, finding out what encyptions work can take DAYS! Yes that goes for "system administrators" too. Too often you get to be sysadmin because you spelled UNIX on a memo once. Not the way its intended, but the real world folks. -- Mike Waters (for your EDIFication) Motorola SMART CAD Group - EDIF (ANSI/EIA std. 548) support Mesa, AZ ...!sun!sunburn!dover!waters OR moto@cad.Berkley.EDU
bill@twwells.uucp (T. William Wells) (11/29/88)
In article <1247@vsi1.UUCP> lmb@vsi1.UUCP (Larry Blair) writes:
: A lot of people thought I was wrong to not just post in the first place.
: I still think that while it will help some sites, it leaves a lot more
: more vulnerable.
I'm of the opinion that you have done the right thing. Those who
cared enough to secure their systems have benefitted; those who
didn't may now pay the price for their carelessness. (This does
ignore those who didn't get the message due to causes beyond their
control, but there is no such thing as a perfect system.)
: One thing that bugs the hell out of me: it takes about 30 seconds to create
: a mail alias, but a lot of supposed administrators sent me mail like, "Gee,
: we don't have a 'news' user here."
Not all news administrators are system administrators; not all of
them are permitted to make aliases. It is entirely possible to run a
newsfeed without any special accounts.
---
Bill
{uunet|novavax}!proxftl!twwells!billglee@cognos.uucp (Godfrey Lee) (11/29/88)
It is in times of chaos and confusion that everyone on the net has the ethical responsibilities to assess and communicate the facts and help everyone else understand and cope with the situation. I found that most people responded in the above spirit and have been very helpful. I did take a second look at my system, and tightened up security where it warranted, without having to turn it into a fortress. I do, however, feel that although the author below has good intentions, he did not hold up his end in being thorough in his analysis and did not communicate it in an even tone. In article <1247@vsi1.UUCP> lmb@vsi1.UUCP (Larry Blair) writes: >I received about 300 requests; not very many. A number of the responses >bounced, 2 of them because AT&T doesn't know about its own machines. Actually, 300 is a lot. If we have 300 secure sites among the 6000 estimated sites in usenet, any virus/worm would have difficulty spreading very far. >A lot of people thought I was wrong to not just post in the first place. Maybe you are a bit paranoid :-) Actually, a lot of people have already pointed out that informed people are the ones best equiped to protect themselves. The virus/worm authors and would be authors can usually find out how to do it without anyone's help, thank you very much. >One thing that bugs the hell out of me: it takes about 30 seconds to create >a mail alias, but a lot of supposed administrators sent me mail like, "Gee, >we don't have a 'news' user here." Don't get bugged, just teach them. >The hole I have discovered in _many_ systems is the use a script for the >automatic unsharing of maps. This is a legitimate concern and should be shared with everyone. I don't agree with some people that everyone knows this hole. Even people who know this hole might not have taken steps to guard against it. >Uuhosts is only slightly more protected. The mapsh program does a chroot >to limit any damage to the directory tree containing the unpacked maps. >All of the commands in the effective /bin allow the creation and overwrite >of file. The danger here is that, besides overwriting everything in the >directory tree including the programs in the /bin, you can run the filesystem >out of space or out of inodes. And since mapsh runs as root, out of space ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >means REALLY out of space. Not quite true. You should have looked at the source for mapsh. It runs as root because you need to be root to do a chroot. The manual pages tell you to run uuhosts as user "news" not "root". The mapsh program does a geteuid to "root", then a "chroot" call, then a getuid to, if you have set it up according to instructions, user "news". >Planting Trojan Horses is also possible. There you go again, either don't make these statements or at least give some plausible scenario so people know where to look! -- Godfrey Lee P.O. Box 9707 Cognos Incorporated 3755 Riverside Dr. VOICE: (613) 738-1338 x3802 FAX: (613) 738-0002 Ottawa, Ontario UUCP: uunet!mitel!sce!cognos!glee CANADA K1G 3Z4
henry@utzoo.uucp (Henry Spencer) (11/29/88)
In article <1247@vsi1.UUCP> lmb@vsi1.UUCP (Larry Blair) writes: >One thing that bugs the hell out of me: it takes about 30 seconds to create >a mail alias, but a lot of supposed administrators sent me mail like, "Gee, >we don't have a 'news' user here." It takes a lot longer than 30 seconds if your mailer doesn't have aliases. Especially if there is some sort of bureaucratic nonsense associated with creating new /etc/passwd entries, which can happen. -- SunOSish, adj: requiring | Henry Spencer at U of Toronto Zoology 32-bit bug numbers. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
clewis@ecicrl.UUCP (Chris Lewis) (11/29/88)
In article <11048@bigtex.cactus.org> james@bigtex.cactus.org (James Van Artsdalen) writes: >> You know, maybe we should try to invent a new "mailable" archive format >> that isn't compatible with /bin/sh so that people are *never* tempted into >> the trap of using sed..|sh or insecure unshars. >Wonderful. What a great idea. Doesn't it seem odd that your goal is >to create an archive layout that nobody can unpack? Huh? > How do you ever >expect people to unpack this stuff? Are *you* going to ensure that >everyone gets a copy of your unpacker, and that vendors all distribute >it? Moi? Did *I* volunteer? ;-) No, I'm not suggesting that that some great-big all-singing all-dancing archiver be built. That you need half an Eagle to recompile... How about something simple, the file format for maps consists of: MAP <name> .... ENDMAP Which can be parsed by two lines of sed. Which can be posted as part of the "README" for maps. >John Quaterman's uuhosts package works. It is secure in the sense >that a worm or virus cannot propogate (a worm could consume CPU cycles >or disk space, but that's about it). Use it. I do. >If anyone has a way of >breaking chroot(2), I'd like to hear about it... Send me mail from your root id and I'll tell you about it. -- Chris Lewis, Markham, Ontario, Canada {uunet!attcan,utgpu,yunexus,utzoo}!lsuc!ecicrl!clewis Ferret Mailing list: ...!lsuc!gate!eci386!ferret-request (or lsuc!gate!eci386!clewis or lsuc!clewis)
clewis@ecicrl.UUCP (Chris Lewis) (11/29/88)
In article <215@twwells.uucp> bill@twwells.UUCP (T. William Wells) writes: >In article <561@redsox.UUCP> campbell@redsox.UUCP (Larry Campbell) writes: >: What's all this about writing gobs of code to decipher some new shar format? >: Why not just chroot(2) to a safe place before feeding the article to sh? > >Because you have to be superuser to chroot. I'm not about to have >chroot(1) be setuid root, so that means writing a special setuid root >program that just chroots so I can then unshar my mail maps. And that >means having One More setuid root program running around on my system. >No thanks. Let me get this straight - you're so afraid of setuid programs that you won't even write your own 4 line C program to chroot and unpack your maps. I take it then that you don't unpack maps. Right? Because it'd be silly to use unprotected unshars if you're afraid of chroots inside programs you've written. Has anybody got a version of uuhosts that is in postable state and (at least vaguely) is up to date? The stuff I've been running predates the Great-Renaming. It would be really nice if a newish version was reposted. Rich? Secondly, can someone out there explain why chroot is privileged? Or why /etc/chroot isn't setuid? It seems pretty darn silly that some mechanism that can only be used for *reducing* access rights requires root permission. If only /etc/chroot allowed anybody to run it, and it carefully made sure that there was a setuid(getuid()) etc before invoking whatever it was going to invoke, the uuhosts unshar would be trivial. -- Chris Lewis, Markham, Ontario, Canada {uunet!attcan,utgpu,yunexus,utzoo}!lsuc!ecicrl!clewis Ferret Mailing list: ...!lsuc!gate!eci386!ferret-request (or lsuc!gate!eci386!clewis or lsuc!clewis)
thomson@hub.toronto.edu (Brian Thomson) (11/29/88)
In article <155@ecicrl.UUCP> clewis@ecicrl.UUCP (Chris Lewis) writes: >Secondly, can someone out there explain why chroot is privileged? Or >why /etc/chroot isn't setuid? It seems pretty darn silly that some >mechanism that can only be used for *reducing* access rights requires >root permission. Some aspects of Unix security depend on the fact that a particular absolute filename always refers to the same object. So, if some privileged program executes /bin/date, or reads /etc/passwd, it knows that it will be getting the Real Goods, because it specified a full pathname. If chroot is allowed, there can be no such assurance. -- Brian Thomson, CSRI Univ. of Toronto utcsri!uthub!thomson, thomson@hub.toronto.edu
henry@utzoo.uucp (Henry Spencer) (11/30/88)
In article <155@ecicrl.UUCP> clewis@ecicrl.UUCP (Chris Lewis) writes: >Secondly, can someone out there explain why chroot is privileged? ... >... It seems pretty darn silly that some >mechanism that can only be used for *reducing* access rights requires >root permission... The latter sentence would be reasonable, except that it does not apply to chroot. Chroot can expand access rights as well as reducing them, because it gives absolute control over the file system, and some parts of the file system are vital to the protection system. For example, login assumes that the file it finds when it opens "/etc/passwd" is the system password file. -- SunOSish, adj: requiring | Henry Spencer at U of Toronto Zoology 32-bit bug numbers. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
jbuck@epimass.EPI.COM (Joe Buck) (11/30/88)
In article <155@ecicrl.UUCP> clewis@ecicrl.UUCP (Chris Lewis) writes: >Secondly, can someone out there explain why chroot is privileged? Or >why /etc/chroot isn't setuid? It seems pretty darn silly that some >mechanism that can only be used for *reducing* access rights requires >root permission. Picture this: mkdir /tmp/etc /tmp/bin cp /bin/sh /tmp/bin echo "root::0:0:Root:/:/bin/sh" > /tmp/etc/passwd /etc/chroot /tmp su The final command runs the "su" command with a root of /tmp. It uses the dummy password file created by the echo command, which has no password for root. You are now root, and you can do another chroot to gain access to the whole system. This is why chroot is privileged! -- - Joe Buck jbuck@epimass.epi.com, or uunet!epimass.epi.com!jbuck, or jbuck%epimass.epi.com@uunet.uu.net for old Arpa sites <picture your favorite pithy quote here>
john@jetson.UPMA.MD.US (John Owens) (11/30/88)
In article <155@ecicrl.UUCP>, clewis@ecicrl.UUCP (Chris Lewis) writes: > Secondly, can someone out there explain why chroot is privileged? Or > why /etc/chroot isn't setuid? Hmm. % ln /bin/su /tmp/su % mkdir /tmp/etc % echo root::0:0::/:/sh > /tmp/etc/passwd % ln /bin/sh /tmp/sh % ln /bin/chown /tmp/chown % ln /bin/chmod /tmp/chmod % cd /tmp % /etc/chroot /tmp /sh $ ./su root # chown root sh # chmod u+s sh # exit $ exit % /tmp/sh $ id ruid=555 euid=0 gid=101 $ ..... [Or some variation of the above; please don't pick on details unless they're fatal to the concept.] In other words, chroot allows you to fool privileged programs that rely on files with particular pathnames (/etc/passwd, /etc/group, /etc/hosts.equiv, /usr/lib/sendmail.cf, /usr/lib/aliases, etc.). -- John Owens john@jetson.UPMA.MD.US uunet!jetson!john +1 301 249 6000 john%jetson.uucp@uunet.uu.net
tytso@athena.mit.edu (Theodore Y. Ts'o) (11/30/88)
In article <155@ecicrl.UUCP> clewis@ecicrl.UUCP (Chris Lewis) writes: >Secondly, can someone out there explain why chroot is privileged? Or >why /etc/chroot isn't setuid? It seems pretty darn silly that some >mechanism that can only be used for *reducing* access rights requires >root permission. If only /etc/chroot allowed anybody to run it, and >it carefully made sure that there was a setuid(getuid()) etc before >invoking whatever it was going to invoke, the uuhosts unshar would >be trivial. Suppose that /tmp is on the same partition as /; or substitute /tmp for some other user writable directory in the same parition as su or some other setuid program you wish to confuse. Assume that chroot is setuid. 1) cd /tmp;mkdir bin etc; ln /bin/su /tmp/bin/su 2) create /tmp/etc/passwd with one line: "root::0:1:::" 3) ln /etc/passwd /tmp/etc/passwd.real 4) chroot /tmp su 5) append to (now) /etc/passwd.real "newroot::0:1:::" 6) GAME OVER. That's why chroot requires setuid priviledges..... =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Theodore Ts'o mit-eddie!mit-athena!tytso 3 Ames St., Cambridge, MA 02139 tytso@athena.mit.edu If it's for real, it isn't!
steve@nuchat.UUCP (Steve Nuchia) (11/30/88)
From article <155@ecicrl.UUCP>, by clewis@ecicrl.UUCP (Chris Lewis): > Secondly, can someone out there explain why chroot is privileged? Or > why /etc/chroot isn't setuid? It seems pretty darn silly that some > mechanism that can only be used for *reducing* access rights requires > root permission. If only /etc/chroot allowed anybody to run it, and > it carefully made sure that there was a setuid(getuid()) etc before > invoking whatever it was going to invoke, the uuhosts unshar would > be trivial. The problem is that other (setuid) programs expect certain files, say /etc/passwd, to be where they belong. Assuming I am an ordinary user with access to a setuid chroot and that /bin and /tmp are on the same file system: mkdir /tmp/bin /tmp/etc ln /bin/su /tmp/bin cp prefab.passwd /tmp/etc/passwd cp /bin/sh /tmp/bin chroot /tmp su /* Look ma, no password! */ chown root /bin/sh chmod 4555 /bin/sh un-chroot /tmp/bin/sh So, don't make chroot easy; it is more powerful than it looks. -- Steve Nuchia South Coast Computing Services uunet!nuchat!steve POB 890952 Houston, Texas 77289 (713) 964 2462 Consultation & Systems, Support for PD Software.
friedl@vsi.COM (Stephen J. Friedl) (11/30/88)
In article <1247@vsi1.UUCP> lmb@vsi1.UUCP (Larry Blair) writes: > [How hard can it be to make a `news' user, dammit] In article <1988Nov28.202412.1828@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes: > It takes a lot longer than 30 seconds if your mailer doesn't have aliases. > Especially if there is some sort of bureaucratic nonsense associated with > creating new /etc/passwd entries, which can happen. System V mailers can do this without aliases or new users. Just do: # cd /usr/mail # echo "Forward to friedl" > news # chown friedl news # chgrp mail news # chmod ug=rw,o= news It took me about thirty seconds. Steve --- Stephen J. Friedl 3B2-kind-of-guy friedl@vsi.com V-Systems, Inc. attmail!vsi!friedl Santa Ana, CA USA +1 714 545 6442 {backbones}!vsi!friedl ---------Nancy Reagan on cutting the grass: "Just say mow"--------
vixie@decwrl.dec.com (Paul A Vixie) (11/30/88)
# You are now root, and you can do another chroot to gain access to the # whole system. Chroot is not reversable. Once you're down, you can't see what was above anymore and therefore there's no way to tell chroot where you'd like to go. -- Paul Vixie Work: vixie@decwrl.dec.com decwrl!vixie +1 415 853 6600 Play: paul@vixie.sf.ca.us vixie!paul +1 415 864 7013
les@chinet.chi.il.us (Leslie Mikesell) (11/30/88)
In article <8219@bloom-beacon.MIT.EDU> tytso@athena.mit.edu (Theodore Y. Ts'o) writes:
[method of using a setuid chroot to modify /etc/passwd deleted]
OK, how about a setuid chroot that checks that either:
A) the new root is not on the same fs as / or
B) the new root contains etc and bin directories that are not
writable by the real uid.
Les Mikeselljbuck@epimass.EPI.COM (Joe Buck) (12/01/88)
In article <VIXIE.88Nov29215911@bacchus.pa.dec.com> vixie@decwrl.dec.com (Paul A Vixie) writes: ># You are now root, and you can do another chroot to gain access to the ># whole system. > >Chroot is not reversable. Once you're down, you can't see what was above >anymore and therefore there's no way to tell chroot where you'd like to go. Another opportunity to be wrong, and I took it. :-) Blush. OK, see the articles by Theodore T'so or John Owens. John's method is more general; you can always make a setuid root shell. -- - Joe Buck jbuck@epimass.epi.com, or uunet!epimass.epi.com!jbuck, or jbuck%epimass.epi.com@uunet.uu.net for old Arpa sites <picture your favorite pithy quote here>
bill@twwells.uucp (T. William Wells) (12/01/88)
In article <155@ecicrl.UUCP> clewis@ecicrl.UUCP (Chris Lewis) writes: : In article <215@twwells.uucp> bill@twwells.UUCP (T. William Wells) writes: : >In article <561@redsox.UUCP> campbell@redsox.UUCP (Larry Campbell) writes: : >: What's all this about writing gobs of code to decipher some new shar format? : >: Why not just chroot(2) to a safe place before feeding the article to sh? : > : >Because you have to be superuser to chroot. I'm not about to have : >chroot(1) be setuid root, so that means writing a special setuid root : >program that just chroots so I can then unshar my mail maps. And that : >means having One More setuid root program running around on my system. : >No thanks. : : Let me get this straight - you're so afraid of setuid programs that : you won't even write your own 4 line C program to chroot and unpack your : maps. Setuid root programs are potential Trojan Horses. That means that reasonable security means keeping a beady eye on each one. I'd rather not have such, if there is a better way. : I take it then that you don't unpack maps. Right? Wrong. As soon as I was notified of my stupidity in using the shell to unpack the maps, I wrote a map unpacker. It now does the work. --- Bill {uunet|novavax}!proxftl!twwells!bill
stefan@mikros.systemware.de (Stefan Stapelberg) (12/01/88)
In article <VIXIE.88Nov29215911@bacchus.pa.dec.com> vixie@decwrl.dec.com (Paul A Vixie) writes: > >Chroot is not reversable. Once you're down, you can't see what was above >anymore and therefore there's no way to tell chroot where you'd like to go. But if you're a real wizard, you can create special device files and examine the filesystem which is above the current root dir. -- Die schaerfsten Kritiker der Elche waren frueher selber welche. -- Traxler
cl@datlog.co.uk (Charles Lambert) (12/02/88)
In article <871@acer.stl.stc.co.uk> dww@acer.UUCP (David Wright) writes: > I've tried 3 times now: once to lmb@vsi1.uucp, once to the >address in his sig (via ames), and once to an address made out of his Path >converted to % form. All three bounced from either ames or from altnet >with 'bad system name', e.g. Same here. I managed to (R)eply to your original posting, Larry, and I received the warning (thanks). But when I tried to reply to your mail message, lmb@vsi1.uucp, it bounced from one of the above-named systems. Charlie
flaps@dgp.toronto.edu (Alan J Rosenthal) (12/02/88)
In article <1971@van-bc.UUCP> sl@van-bc.UUCP (pri=-10 Stuart Lynne) writes: >Anyone else who has unshar for a pc (as in personal computer, generic, not >necessarily ibm) might look at retro-fitting to Unix and posting. It seems >to me that when I was Mac'ing I had one running under Aztec C that had come >from the Amiga world. This may very well be the version by Craig Norborg. My version is marked with a copyright date of 4 June 1987. It compiles without modification both under Aztec C on the Amiga and under unix, and probably everywhere else too. It is redistributable so long as the copyright notice is preserved and selling and marketing are not involved. I will send it by e-mail to all who ask, unless huge numbers of people ask. (Please check with others around you first.) ajr <flaps@dgp.toronto.edu>
engelson@cs.yale.edu (Sean Philip Engelson) (12/03/88)
In article <366@mikros.systemware.de>, stefan@mikros (Stefan Stapelberg) writes: >In article <VIXIE.88Nov29215911@bacchus.pa.dec.com> vixie@decwrl.dec.com (Paul A Vixie) writes: >> >>Chroot is not reversable. Once you're down, you can't see what was above >>anymore and therefore there's no way to tell chroot where you'd like to go. > >But if you're a real wizard, you can create special device files >and examine the filesystem which is above the current root dir. > >-- > Die schaerfsten Kritiker der Elche > waren frueher selber welche. -- Traxler How about this: ln -s / /tmp/root <make fake etc passwd in /tmp> cd /tmp chroot /tmp su root chroot /tmp/root Ta Da! Instant superuser! -Sean- ---------------------------------------------------------------------- Sean Philip Engelson, Gradual Student Yale Department of Computer Science 51 Prospect St. New Haven, CT 06520 ---------------------------------------------------------------------- G-d, according to Einstein, does not play dice with the world. Well, maybe; but He sure is into shell games. --Jerry Fodor in "Modules, Frames, Fridgeons, Sleeping Dogs, and the Music of the Spheres"
allbery@ncoast.UUCP (Brandon S. Allbery) (12/03/88)
As quoted from <1247@vsi1.UUCP> by lmb@vsi1.UUCP (Larry Blair): +--------------- | One thing that bugs the hell out of me: it takes about 30 seconds to create | a mail alias, but a lot of supposed administrators sent me mail like, "Gee, | we don't have a 'news' user here." +--------------- Your posting said that you would respond only to mail sent BY the user "news". Aliases don't help with that; you have to log in as "news" to get that name as the sender, modulo uucp or smtp forgery. ++Brandon -- Brandon S. Allbery, comp.sources.misc moderator and one admin of ncoast PA UN*X uunet!hal.cwru.edu!ncoast!allbery <PREFERRED!> ncoast!allbery@hal.cwru.edu allberyb@skybridge.sdi.cwru.edu <ALSO> allbery@uunet.uu.net comp.sources.misc is moving off ncoast -- please do NOT send submissions direct Send comp.sources.misc submissions to comp-sources-misc@<backbone>.
brian@ucsd.EDU (Brian Kantor) (12/04/88)
>In article <871@acer.stl.stc.co.uk> dww@acer.UUCP (David Wright) writes: >... All three bounced from either ames ... Ames is one of our uucp neighbors; we see a lot of bounces from them. But it isn't their fault! Nearly every one of the bounced messages turns out to be a reply to mail that passed through host 'pacbell' before it got to ames. 'pacbell' doesn't add its sitename to the "From:" line in mail, but does add it to the "From " line. Berkeley mail (/usr/ucb/mail) uses the "From:" line to generate the address when replying to mail, so what happens is something like this: Message arrives as From ames!pacbell!hoptoad!gnu From: ames!hoptoad!gnu To: irrelevant and when you reply to it with Berkeley mail, your response gets mailed to To: ames!hoptoad!gnu which probably won't get there. The system administrator at host 'pacbell' claims he's doing the right thing. I think he's wrong. There it stands. I'm told this same problem occurs with lots of other BSD cum SysV mail paths. I know I've seen it elsewhere. There is no quick fix. You have been warned. Brian Kantor UCSD Postmaster UCSD Office of Academic Computing (619) 534-6865 UCSD B-028, La Jolla, CA 92093 USA brian@ucsd.edu BRIAN@UCSD ucsd!brian
clewis@ecicrl.UUCP (Chris Lewis) (12/05/88)
In article <1988Nov29.181037.23528@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >In article <155@ecicrl.UUCP> clewis@ecicrl.UUCP (Chris Lewis) writes: >>Secondly, can someone out there explain why chroot is privileged? ... >>... It seems pretty darn silly that some >>mechanism that can only be used for *reducing* access rights requires >>root permission... > >The latter sentence would be reasonable, except that it does not apply >to chroot. Chroot can expand access rights as well as reducing them, >because it gives absolute control over the file system, and some parts >of the file system are vital to the protection system. For example, >login assumes that the file it finds when it opens "/etc/passwd" is the >system password file. Thanks Henry (and literally dozens of others) for pointing out the problems of world-executable chroot. What a dumb question to ask. [I mailed out a response about the other chroot issue - if you don't get your reply soon, please resend a request from your root account] Getting back for a moment to map unpacking - I think that the point has been well made about automatic map unpacking being unsafe unless you use uuhosts or something similar. It was rather funny seeing the "but I'm safe because I use unshar" remarks, and then later those same people finding out that their unshar is *probably* (you get that? "probably" - there are literally hundreds of versions of unshar out there - don't flame me if you happen to have one of the one or two that doesn't use /bin/sh) extremely unsafe. I still think it would be a really good idea to come up with a new format for map postings, so that we don't have to go through this fuss about security holes over and over again as new SA's come online and use the easy way out. As expressed by Scot Wilcoxon (datapg!sewilco) "Actually, that's a good idea. There's no need for that single-purpose newsgroup to have contents which are so flexible as to need shar." What I propose is the following for the contents of map articles: MAP <name of map> <rest of information> <contents of map> ENDMAP Where: <name of map> (eg: u.can.on.1) is a simple file name - no slashes etc allowed <rest of information> is some tokens that would be ignored by unpacking, but could be used for other things. <contents of map> is a copy of the body of the map, with lines that start with things likely to cause problems (like a site "ENDMAP", or periods) prepended with an "X" (ala sed-style unshars) If there's any interest in this on the part of the keepers-of-the-maps, I'll write a small package to do this. Presumably the best way would be to distribute it along with the maps and then cut over at some future date. H'm, as a transitional step, we could do both at once. Eg: cat > <name-of-map> << 'END-OF-SHAR' #MAP <name of map> <contents of map> #ENDMAP END-OF-SHAR Hey, some of the maps already come out looking very much like this already: > : This is a shell archive. > : Remove everything above this line and > : run the following text with /bin/sh to create: > : u.usa.va.1 > : This archive created: Fri Dec 2 01:22:05 1988 > echo shar: extracting u.usa.va.1 > cat << 'SHAR_EOF' > u.usa.va.1 > #MAP FILE: u.usa.va.1 Thu Dec 1 16:59:15 PST 1988 rob@violet.berkeley.edu > # > # > > #N aaachoo > #S AT&T 3B2/500, Sys V 3.2 > .... > yendor hqda-ai(DIRECT+HIGH), media(DAILY), bjs(DIRECT), > arc6000(DIRECT), ozzie(DIRECT) > # > # > #MAP FILE END: u.usa.va.1 Thu Dec 1 16:59:30 PST 1988 rob@violet.berkeley.edu > SHAR_EOF Note the MAP FILE entries. -- Chris Lewis, Markham, Ontario, Canada {uunet!attcan,utgpu,yunexus,utzoo}!lsuc!ecicrl!clewis Ferret Mailing list: ...!lsuc!gate!eci386!ferret-request (or lsuc!gate!eci386!clewis or lsuc!clewis)
dws@cseg.uucp (David W. Summers) (12/08/88)
In article <157@ecicrl.UUCP>, clewis@ecicrl.UUCP (Chris Lewis) writes: > [ deleted ] > Getting back for a moment to map unpacking - I think that the point has > been well made about automatic map unpacking being unsafe unless you use > uuhosts or something similar. It was rather funny seeing the "but I'm > safe because I use unshar" remarks, and then later those same people finding > out that their unshar is *probably* (you get that? "probably" - there are > literally hundreds of versions of unshar out there - don't flame me if > you happen to have one of the one or two that doesn't use /bin/sh) extremely > unsafe. > > I still think it would be a really good idea to come up with a new > format for map postings, so that we don't have to go through this fuss > about security holes over and over again as new SA's come online and > use the easy way out. As expressed by Scot Wilcoxon (datapg!sewilco) [...] That is a good idea, but what is wrong with the this? ================================================================================ #! /bin/sh #This program un-archives the map info and stores it in the map directory. cd /usr2/netnews/maps sed -e '1,/^echo/d' -e '/^SHAR_EOF/,$d' | ( read CAT IN TERMINATOR OUT FILENAME if [ "$CAT" != cat -o "$IN" != '<<' -o "$TERMINATOR" != \'SHAR_EOF\' -o "$OUT" != '>' ] then echo "$0: bad shar format." echo "First line after echo is:" echo "$CAT $IN $TERMINATOR $OUT $FILENAME" echo Map file ignored. exit else cat >./`basename $FILENAME` fi ) ================================================================================ The program doesn't use 'sh', and no-one can force the file into another directory because of the 'basename' command as it is put into the maps directory. Can anyone find something wrong with this so I can improve it even more? Thanks to who-ever provided much of this script....I was using 'sed' and 'sh' until your script came along and I decided to protect myself as much as is resonable. The main thing that I can see wrong is that someone could still corrupt the map up-stream of my site, but since I'm only 2-3 sites away from 'rutgers' I don't consider this too much of a problem. Any comments or suggestions appreciated. - David Summers (dws@cseg.uucp) (..!ksuvax1!harry!hcx!cseg!dws)