Re: Bug#27050 (fdutils): A cause for security concern?
Previously Anthony Fok wrote: > Unfortunately, the suggestion "chown root.floppy" and "chmod [12]754" > won't work either because fdmount.c has this check in it: > > if (geteuid()!=0) > die("Must run with EUID=root"); You wouldn't believe how many programs have a check like this and still work perfectly when they are not root.. Wichert. -- == This combination of bytes forms a message written to you by Wichert Akkerman. E-Mail: [EMAIL PROTECTED] WWW: http://www.wi.leidenuniv.nl/~wichert/ pgpr5jlgIGX25.pgp Description: PGP signature
Re: Bug#27050 (fdutils): A cause for security concern?
Ben Collins wrote: > Any program that is suid or sgid for no reason what-so-ever is always a > reason for a bug report, especially if it's suid root...we need some > automatic catch for new packages that have suid or sgid binaries in > them, or call suidregister. Lintian can serve as a check for the former case. See http://master.debian.org/~dark/lintian/reports/Tsetuid-binary.html I don't think it handles suidmanager yet. -- see shy jo
Re: Bug#27050 (fdutils): A cause for security concern?
> "AF" == Anthony Fok <[EMAIL PROTECTED]> writes: AF> if (geteuid()!=0) die("Must run with EUID=root"); AF> I am a little bit tempted to comment that line out, but it's AF> probably there for a reason, and I am definitely not qualified AF> to hack fdmount.c, so for now I should probably add a AF> /usr/sbin/fdutilsconfig as Thomas has suggested. This sort of thing should be shot on sight. It will need to be removed one way or another when we move to a capability based system. The downside is that the reason things like this exist is the complete lack of any error handling in the rest of the code. If you need something to do, dike it out. If it's run as root, it will work as expected. If not, then it can't do any real damage, right? ;) m.
Re: Bug#27050 (fdutils): A cause for security concern?
Hello Ben, Avery and Wichert! On Wed, Jan 20, 1999 at 12:50:59AM +0100, Wichert Akkerman wrote: > Previously Anthony Fok wrote: > > As the Slink deep freeze and release are impending, I would like to ask your > > advice: Should I follow the suggestion given by the bug reporter Thomas > > Roessler? > > I think so. For people who want to mount floppies without being root > you can also use a line in /etc/fstab like this: > > /dev/fd0 /floppyauto noauto,noexec,nodev,user 0 0 Yes, I already have something similar in my /etc/fstab. The problem is that fdmount is independent of mount. It doesn't even touch /etc/fstab. Unfortunately, the suggestion "chown root.floppy" and "chmod [12]754" won't work either because fdmount.c has this check in it: if (geteuid()!=0) die("Must run with EUID=root"); I am a little bit tempted to comment that line out, but it's probably there for a reason, and I am definitely not qualified to hack fdmount.c, so for now I should probably add a /usr/sbin/fdutilsconfig as Thomas has suggested. > fdmount should probably be audited so we really know if it's secure. You > could submit it to the security-auditing list > ([EMAIL PROTECTED]). Thanks for the info! > > If so, should I fix this bug before Slink is out? > > Yes. I would hate to discover a vulnerability and release an advisory > days after we release slink.. Okay, I will try to do it soon then. Hopefully I will have my school assignments finished before the end of the weekend. :-) Thanks a lot for all your advice and suggestions! Anthony -- Anthony Fok Tung-LingCivil and Environmental Engineering [EMAIL PROTECTED], [EMAIL PROTECTED]University of Alberta, Canada [EMAIL PROTECTED] Keep smiling! *^_^* Come visit Our Lady of Victory Camp -- http://www.olvc.ddns.org/ or http://www.ualberta.ca/~foka/OLVC/
Re: Bug#27050 (fdutils): A cause for security concern?
Wichert Akkerman writes: > It might be much easier to just replace them with snprintf's. That is what I meant when I said I know how to fix them. > Also check for things like strcpy()... I'd rather trace out the input string handling than just grep for dangerous functions. There isn't that much of it. The few strcpy's I found look safe, but I can think of ways to overrun a buffer without using any functions known to be dangerous. > insecure handling of files, etc. No files. What there is, however, is a password being sent in a udp packet. I haven't finished figuring out how he handles it, but it looks sniffable to me. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI
Re: Bug#27050 (fdutils): A cause for security concern?
Previously John Hasler wrote: > As I noted, there are no calls to system or its ilk. That's good. > I know how to fix the sprintf's. My plan now is to analyze the path > followed by strings from input to consumption. It might be much easier to just replace them with snprintf's. Also check for things like strcpy(), insecure handling of files, etc. Wichert. -- == This combination of bytes forms a message written to you by Wichert Akkerman. E-Mail: [EMAIL PROTECTED] WWW: http://www.wi.leidenuniv.nl/~wichert/ pgpD9vb5l6WkV.pgp Description: PGP signature
Re: Bug#27050 (fdutils): A cause for security concern?
I wrote: > I looked around in the code a bit more and found a few dubious looking > sprintf's. What else should I look for? I already checked for 'system' > and 'execve'. Wichert Akkerman writes: > Please do so. Please do *what*? As I noted, there are no calls to system or its ilk. I know how to fix the sprintf's. My plan now is to analyze the path followed by strings from input to consumption. The control port is protected by a password: I'll look for holes in the password checking. What else? -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI
Re: Bug#27050 (fdutils): A cause for security concern?
Previously John Hasler wrote: > I looked around in the code a bit more and found a few dubious looking > sprintf's. What else should I look for? I already checked for 'system' > and 'execve'. Please do so. If you don't feel confident enough you can submit it to the security team. We'll take a look at it if/when we can find the time then. Wichet. -- == This combination of bytes forms a message written to you by Wichert Akkerman. E-Mail: [EMAIL PROTECTED] WWW: http://www.wi.leidenuniv.nl/~wichert/ pgpdkAZtXzu8d.pgp Description: PGP signature
Re: Bug#27050 (fdutils): A cause for security concern?
Wichert writes: > Have you tried running it [chronyd] as another user? No, but it doesn't seem too likely that a program that adjusts the system clock would work too well running as 'nobody'. It can also be an ntp server, though that is turned off in the default configuration. I looked around in the code a bit more and found a few dubious looking sprintf's. What else should I look for? I already checked for 'system' and 'execve'. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI
Re: Bug#27050 (fdutils): A cause for security concern?
Previously John Hasler wrote: > It isn't. My chrony package includes a daemon that runs as root. I've > looked it over and don't see any holes, but I'm not a security expert. Have you tried running it as another user? Wichert. -- == This combination of bytes forms a message written to you by Wichert Akkerman. E-Mail: [EMAIL PROTECTED] WWW: http://www.wi.leidenuniv.nl/~wichert/ pgpZkthCvRW1V.pgp Description: PGP signature
Re: Bug#27050 (fdutils): A cause for security concern?
I wrote: > Would you say the same of daemons that run as root? Avery Pennarun writes: > Coming from you, that sounds like a trick question. It isn't. My chrony package includes a daemon that runs as root. I've looked it over and don't see any holes, but I'm not a security expert. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI
Re: Bug#27050 (fdutils): A cause for security concern?
On Tue, Jan 19, 1999 at 08:56:11PM -0600, John Hasler wrote: > Avery Pennarun wrote: > > When the docs for a setuid program warn you "not to trust its security" > > then be afraid, be very afraid. It shouldn't be automatically setuid in > > Debian until _some_ security-conscious person has audited it carefully. > > Would you say the same of daemons that run as root? Coming from you, that sounds like a trick question. Okay, I volunteer to be tricked: yes, daemons should not run as root (especially network servers) unless they've been looked over by some security-competent person, and only if they actually NEED to run as root! I don't know its current status, but I submitted a bug against socks4-server a while ago because it was running as root for no reason at all -- it works fine when running as "nobody." Setuid programs are actually more dangerous than daemons, though -- the non-root user has more complete control over their execution environment, so there are more types of security holes. For example, you can change the PATH environment variable and shell strings (eg. IFS, HOME, etc) so using the system() and execvp() system calls is generally dangerous in a setuid program, but often not so bad in a daemon. Have fun, Avery
Re: Bug#27050 (fdutils): A cause for security concern?
On Wed, Jan 20, 1999 at 02:18:59PM +1300, Robert Donn wrote: > I'm not sure whether this violates policy or not (and thus whether to file a > bug against it) - but Policy does not require postinsts using > chmod/suidregister to give message or query, then perhaps it > needs to be added... Any program that is suid or sgid for no reason what-so-ever is always a reason for a bug report, especially if it's suid root...we need some automatic catch for new packages that have suid or sgid binaries in them, or call suidregister. -- --- - - --- - - - --- Ben Collins <[EMAIL PROTECTED]> Debian GNU/Linux UnixGroup Admin - Jordan Systems Inc. [EMAIL PROTECTED] -- -- - - - --- --- -- The Choice of the GNU Generation
Re: Bug#27050 (fdutils): A cause for security concern?
Avery Pennarun wrote: > When the docs for a setuid program warn you "not to trust its security" > then be afraid, be very afraid. It shouldn't be automatically setuid in > Debian until _some_ security-conscious person has audited it carefully. Would you say the same of daemons that run as root? -- John HaslerThis posting is in the public domain. [EMAIL PROTECTED] Do with it what you will. Dancing Horse Hill Make money from it if you can; I don't mind. Elmwood, Wisconsin Do not send email advertisements to this address.
Re: Bug#27050 (fdutils): A cause for security concern?
On Tue, Jan 19, 1999 at 05:16:01PM -0500, Avery Pennarun wrote: > When the docs for a setuid program warn you "not to trust its security" > then be afraid, be very afraid. It shouldn't be automatically setuid in > Debian until _some_ security-conscious person has audited it carefully. On a related note, I recently had a relatively grave security concern with the 'xzx' package (a ZX Spectrum emulator for X) - after it faulted one time (can't remember what happened - I think it just stopped responding to closing the window and using 100% CPU), I had a number of things go wrong - I checked out the binary itself, and found it was suid root! Now, the postinst (which sets the suid bit) never warned me about this, and I can also see no reason for it to be suid root - it doesn't appear to give up root priviledges once started (and contains file dialogs). I'm not sure whether this violates policy or not (and thus whether to file a bug against it) - but Policy does not require postinsts using chmod/suidregister to give message or query, then perhaps it needs to be added... -- Robert Donn
Re: Bug#27050 (fdutils): A cause for security concern?
Previously Anthony Fok wrote: > As the Slink deep freeze and release are impending, I would like to ask your > advice: Should I follow the suggestion given by the bug reporter Thomas > Roessler? I think so. For people who want to mount floppies without being root you can also use a line in /etc/fstab like this: /dev/fd0 /floppyauto noauto,noexec,nodev,user 0 0 fdmount should probably be audited so we really know if it's secure. You could submit it to the security-auditing list ([EMAIL PROTECTED]). > If so, should I fix this bug before Slink is out? Yes. I would hate to discover a vulnerability and release an advisory days after we release slink.. Wichert. -- == This combination of bytes forms a message written to you by Wichert Akkerman. E-Mail: [EMAIL PROTECTED] WWW: http://www.wi.leidenuniv.nl/~wichert/ pgpotBh2GpOsx.pgp Description: PGP signature
Re: Bug#27050 (fdutils): A cause for security concern?
On Tue, Jan 19, 1999 at 04:43:37PM -0500, Ben Collins wrote: > On Tue, Jan 19, 1999 at 02:29:44PM -0700, Anthony Fok wrote: > > As the Slink deep freeze and release are impending, I would like to ask > > your advice: Should I follow the suggestion given by the bug reporter > > Thomas Roessler? If so, should I fix this bug before Slink is out? I > > am kind of busy with school now and would like to put it off till the > > holiday, but if all of you experienced developers feel that it is > > urgent, I will try to fix it before Slink is released. > > I would suggest making it sgid to group floppy, them make it mode 2754. > There doesn't seem to be a need to have it suid root since /dev/fd? is > writable by group floppy. I don't think you can mount filesystems unless you're root. > 1) Only people in group floppy will be able to execute it, That's a useful feature, though. You could make it owned by root.floppy, mode 1754. (There is no real need to make it setgid floppy in any case.) When the docs for a setuid program warn you "not to trust its security" then be afraid, be very afraid. It shouldn't be automatically setuid in Debian until _some_ security-conscious person has audited it carefully. Have fun, Avery
Re: Bug#27050 (fdutils): A cause for security concern?
On Tue, Jan 19, 1999 at 02:29:44PM -0700, Anthony Fok wrote: > As the Slink deep freeze and release are impending, I would like to ask your > advice: Should I follow the suggestion given by the bug reporter Thomas > Roessler? If so, should I fix this bug before Slink is out? I am kind of > busy with school now and would like to put it off till the holiday, but if > all of you experienced developers feel that it is urgent, I will try to fix > it before Slink is released. I would suggest making it sgid to group floppy, them make it mode 2754. There doesn't seem to be a need to have it suid root since /dev/fd? is writable by group floppy. It gives three advantages, 1) Only people in group floppy will be able to execute it, which gives the admin more control, 2) The admin can setup login.defs to give console users group floppy automatically, a bug plus since people only need to access the floppy when they have physical access any way, and 3) it is way more secure than suid root, at worst if the program is exploitable, you only stand to lose floppy data as opposed to your entire machine. -- --- - - --- - - - --- Ben Collins <[EMAIL PROTECTED]> Debian GNU/Linux UnixGroup Admin - Jordan Systems Inc. [EMAIL PROTECTED] -- -- - - - --- --- -- The Choice of the GNU Generation
Bug#27050 (fdutils): A cause for security concern?
Hello, I received the following bug report about fdutils a while ago, but haven't had time to deal with it yet. Basically, the bug reporter is concerned that the suid'ed fdmount could be insecure, because fdmount's manpage warns the user not to rely on it being secure. So far, my suid'ed fdmount hasn't given me any trouble, and the upstream defaults to suid'ing it, and I haven't heard any security warnings from CERT (?) etc. either. However, I have to admit that I do not know that much about security. As the Slink deep freeze and release are impending, I would like to ask your advice: Should I follow the suggestion given by the bug reporter Thomas Roessler? If so, should I fix this bug before Slink is out? I am kind of busy with school now and would like to put it off till the holiday, but if all of you experienced developers feel that it is urgent, I will try to fix it before Slink is released. Thanks again. :-) I have attached the bug report below. Cheers, Anthony Package: fdutils; Reported by: Thomas Roessler <[EMAIL PROTECTED]>; dated Thu, 24 Sep 1998 15:33:01 GMT; Maintainer for fdutils is Anthony Fok <[EMAIL PROTECTED]>. == Package: fdutils Version: 5.2pl4-3 [This is on a current hamm system.] Even fdmount's own manual page says that users should not rely on the program being secure. I consider it a bug that the fdutils package installs this program suid root regardless of this warning. Either you have checked the program's security - in this case you may install it suid root and remove the warning from the manual page. Or you didn't do the checks you should - in this case you should release a new package which installs the program mode 755 by default and tells the user that he can get full functionality only when registering it suid root. (gnuplot does something like this using suidmanager.) Regards, tlr -- System Information Debian Release: 2.0 Kernel Version: Linux sobolev 2.1.122 #43 SMP Thu Sep 17 14:24:19 MEST 1998 i586 unknown Versions of the packages fdutils depends on: ii libc6 2.0.7t-1 The GNU C library version 2 (run-time files) ii makedev 1.6-32 Creates special device files in /dev. -- Anthony Fok Tung-LingCivil and Environmental Engineering [EMAIL PROTECTED], [EMAIL PROTECTED]University of Alberta, Canada [EMAIL PROTECTED] Keep smiling! *^_^* Come visit Our Lady of Victory Camp -- http://www.olvc.ddns.org/ or http://www.ualberta.ca/~foka/OLVC/