krieg@jupiter.med.ge.com (Andrew Krieg) (12/29/90)
uudecode has some special characteristics at my site. We are running a large Sun network, using SunOS 3.5. uudecode will only work in the /tmp or /usr/tmp directories. If you try to run it, say in your home directory, you get the error: filename: Permission denied It also won't work from within a makefile. You get the same error, even if the makefile tries to do the uudecode in /tmp. Anyone have a clue as to why this is? The man pages sure don't list this as a feature. Is there perhaps something wrong with the configuration or installation at my site? Thanks. -- ========================================================================= = Andrew Krieg | Down by the river bank, a blues band arrives. = = krieg@titan.med.ge.com| The music suffers, baby. = = or | The music business thrives. = = krieg@cvax.cs.uwm.edu | - Paul Simon = =========================================================================
ronald@robobar.co.uk (Ronald S H Khoo) (12/29/90)
krieg@titan.med.ge.com (Andrew Krieg) writes: > uudecode has some special characteristics at my site. > If you try to run it, say in your home directory, you > get the error: > > filename: Permission denied Ha! I think your vendor has made the *dreadful* error of making uudecode setuid to uucp "for the convenience of decoding received uucp files". I have seen systems where this is a horrible security hole in that uudecode will allow anyone to make a setuid-to-uucp shell (begin 4755 sh) and so gain access to L.sys and the passwords therein (especially nasty if L.sys contains passwords to expensive PDN network gateways). I would encourage you to tell your system administrator to remove the setuid bit on uudecode (chmod ug-s /usr/bin/uudecode) and shout at your vendor. It's this sort of thing that gives UNIX system security a bad name. -- ronald@robobar.co.uk +44 81 991 1142 (O) +44 71 229 7741 (H)
jeff@onion.pdx.com (Jeff Beadles) (12/30/90)
In <3317@mrsvr.UUCP> krieg@titan.med.ge.com (Andrew Krieg) writes: >uudecode has some special characteristics at my site. We are running a large >Sun network, using SunOS 3.5. uudecode will only work in the /tmp or >/usr/tmp directories. If you try to run it, say in your home directory, you >get the error: >filename: Permission denied ... >Anyone have a clue as to why this is? The man pages sure don't list this as >a feature. Is there perhaps something wrong with the configuration or >installation at my site? Well, on some Sun's I've been told that uuencode/decode is suid. This is a silly, mindless thing to do (IMHO, of course :-). With this, the directory that you are uudecoding into MUST be either publically writable, or at least writable by the owner of the uudecode program. One thing that you could do is to put it in a private directory without being setuid. Ie: % echo $PATH /usr/jeff/.bin:/bin:/usr/bin:... (Note that my private .bin is first in my path before the system's /bin) cp /bin/uuencode ~/.bin/uuencode (Do the same for uudecode) chmod 755 ~/.bin/uuencode (Do the same for uudecode) Then, it should run as a normal program (hopefully) If not, either complain loudly to Sun, or go to uunet and get the BSD free'd version and compile it. -Jeff -- Jeff Beadles jeff@onion.pdx.com
tronix@polari.UUCP (David Daniel) (12/30/90)
[]Ha! I think your vendor has made the *dreadful* error of making
[]uudecode setuid to uucp "for the convenience of decoding received uucp
[]files". I have seen systems where this is a horrible security hole in
[]that uudecode will allow anyone to make a setuid-to-uucp shell (begin 4755
[remainder of security hole explanation deleted]
Even
though you've told the net at large and who knows how many BBS's
around the world exactly how to hack a specific system and possibly
others I'll make a suggestion:
You should have answered this person via e-mail with a cc to root. I'm
glad I don't have an account on his system.
--
David Daniel (The man with no disclaimer) tronix@polari.UUCP
"Beware the Truth. If you find a Truth it can demand that you make painful
changes." - Frank Herbertronald@robobar.co.uk (Ronald S H Khoo) (12/31/90)
[ this really wants to go to alt.security.d, but seeing as it doesn't exist, I've redirected to alt.security. Sorry folx ] tronix@polari.UUCP (David Daniel) writes: > [remainder of security hole explanation deleted] [ the setuid-to-uucp uudecode one ] > You should have answered this person via e-mail with a cc to root. Nope. It's a general interest question that pops up from time to time, sometimes I give the answer, sometimes I don't. Maybe it should go into the FAQ. It's hardly new, nor is it hard to find (find / -perm would have found it straight away, and I can't see any half competent cracker missing that trick) Has someone got a summary of the last 30 "you should not have posted that, Oh yes I should, Oh no you shouldn't" discussions taht we've had which they can mail to Mr. Daniel ? > I'm glad I don't have an account on his system. Why? What can a cracker do with a uucp shell? Get network passwords to fund his cracking with ? Forge mail (that's easy enough anyway) ? That's his sysadmin's problem, not yours. Nothing to crack *your* account with that I know of, unless someone knows one. Please post. If such a hole exists, I want to plug it. Ronald, at this point, pretty fed up with all this pettiness... -- ronald@robobar.co.uk +44 81 991 1142 (O) +44 71 229 7741 (H)
pizzi@esacs.UUCP (Riccardo Pizzi) (01/10/91)
In article <3036@polari.UUCP> tronix@polari.UUCP (David Daniel) writes: >[]Ha! I think your vendor has made the *dreadful* error of making >[]uudecode setuid to uucp "for the convenience of decoding received uucp >[]files". I have seen systems where this is a horrible security hole in >[]that uudecode will allow anyone to make a setuid-to-uucp shell (begin 4755 > > [remainder of security hole explanation deleted] >Even >though you've told the net at large and who knows how many BBS's >around the world exactly how to hack a specific system and possibly >others I'll make a suggestion: >You should have answered this person via e-mail with a cc to root. I'm >glad I don't have an account on his system. I do not agree with you, by the way. The information about security holes is of big interest for the entire USENET community; it is stupid to try to hide things like this because of being afraid of hackers. Just remember: hackers already knows many of them, while most system admin don't. Not being an hacker, I understand that a system admin is not able to find all the possible ways to hack a system just because that is not his goal, but is the hacker's one. I don't remember the name of the guy who explained the uudecode security hole, but I want to publicly thank him for the advice. Rick -- Riccardo Pizzi @ ESA Software, Rimini, ITALY e-mail: pizzi%esacs@relay.EU.net -or- root@xtc.sublink.org Public Access Unix @ +39-541-27858 (Telebit) << Object Oriented is an Opaque Disease >>