From: M. S. <lm...@fe...> - 2006-02-07 12:00:55
|
Hello all, Iam the security advisor at Oportos University School of Engineering in Por= tugal and i found a bug while pen testing some of our equipments. I didnt know your software but, after 'googling' a little, i saw it is used= by a reasonable number of people. Either way, i havent examined the code in depth so i cant really understand= why it needs to be run as root (tipically via sudo?). This causes a security flaw (at least on your "opcontrol script"). After a quick analisys of that script i found that: root@D00BP0916:~# cat /usr/local/bin/opcontrol | grep which # A replacement function for the sysctl (procps package) utility which is #determine which module is loaded OPCONTROL=3D`which $0` root@D00BP0916:~# You do this to check where the program is running from *but* dont actually = do that same test on the 'which' binary. Allthough there is a forced 'PATH' definition about 2 lines later, this mea= ns that any user can force a script named which (with arbitrary commands) to b= e run as root. A example exploit follows: Example: cat > which #!/bin/sh /bin/cp /etc/shadow /tmp/myshadow /bin/chmod 644 /tmp/myshadow ^C export PATH=3D"." && export path=3D"." /usr/bin/sudo /usr/local/bin/opcontrol Best regards, +--------------------------------- | Lu=EDs Miguel Ferreira da Silva | Unidade de Qualidade e Seguran=E7a | Centro de Inform=E1tica | Professor Correia Ara=FAjo | Faculdade de Engenharia da | Universidade do Porto |
From: John L. <le...@mo...> - 2006-02-07 15:01:47
|
On Tue, Feb 07, 2006 at 12:00:21PM +0000, Luís Miguel Silva wrote: > This causes a security flaw (at least on your "opcontrol script"). You're using sudo (a completely broken 'feature' in the first place). This problem is only a security flaw if you've decided to do this (or foolishly have "." in root's $PATH); we've never recommended sudo precisely because nobody has audited opcontrol (and it's near impossible to audit, given it's a shell script). That said, I wouldn't object to a patch to make it use /usr/bin/which if you're otherwise happy throwing around privilege to unaudited code. regards john |
From: M. S. <lm...@fe...> - 2006-02-07 18:08:17
|
Dear John, Thank you for your quick reply. However, i must say i was quite sad with your agressive reply. Either way, i would just like you to take some web pages into consideration= : http://www.redhat.com/magazine/012oct05/features/oprofile/ http://devforums.amd.com/lofiversion/index.php/t359.html https://www.redhat.com/archives/fedora-devel-java-list/2005-March/msg00117.= html https://uimon.cern.ch/twiki/bin/view/FIOgroup/LxbuildInfo http://prospect.sourceforge.net/ "if use of oprofile is required: we need to give sudo access to the users to be able to start the profiling, so please give us the list of logins that need it" PS: actually, you dont need to have "." in the administrators path to explo= it this :o) PS2: i dont really understand your agressive response. It is quite obvious that whoever did that opcontrol script tried to correct the security bug i mentioned by exporting a "safe" PATH on the script...(however...it should be about 2 lines sooner ;oP). PS3: regarding the "it's nearly impossible to audit given it's a shell script", i must disagree. The fact that it is a script only makes the task a lot simpler. PS4: as you can see, even a article on the official redhat site mentions the use of 'sudo'. PS5: feel free to contact me if you need any help. Best regards, Lu=EDs Silva Quoting John Levon <le...@mo...>: > On Tue, Feb 07, 2006 at 12:00:21PM +0000, Lu=EDs Miguel Silva wrote: > >> This causes a security flaw (at least on your "opcontrol script"). > > You're using sudo (a completely broken 'feature' in the first place). > This problem is only a security flaw if you've decided to do this (or > foolishly have "." in root's $PATH); we've never recommended sudo > precisely because nobody has audited opcontrol (and it's near impossible > to audit, given it's a shell script). > > That said, I wouldn't object to a patch to make it use /usr/bin/which if > you're otherwise happy throwing around privilege to unaudited code. > > regards > john |
From: John L. <le...@mo...> - 2006-02-07 16:10:28
|
On Tue, Feb 07, 2006 at 03:59:23PM +0000, Luís Miguel Silva wrote: > http://www.redhat.com/magazine/012oct05/features/oprofile/ > http://devforums.amd.com/lofiversion/index.php/t359.html > https://www.redhat.com/archives/fedora-devel-java-list/2005-March/msg00117.html > https://uimon.cern.ch/twiki/bin/view/FIOgroup/LxbuildInfo > http://prospect.sourceforge.net/ I don't think we can be held responsible for what other people recommend. > PS2: i dont really understand your agressive response. It is quite > obvious that whoever did that opcontrol script tried to correct the > security bug i mentioned by exporting a "safe" PATH on the > script...(however...it should be about 2 lines sooner ;oP). As I mentioned I'd welcome a patch to fix this particular problem. However, no security audit has been done and I'm afraid I don't agree that auditing a shell script is easy. This is why we won't recommend using problematic features like sudo until somebody trustworthy does this audit. (And I suspect the audit would only make sense for the GUI, not the shell script.) > PS4: as you can see, even a article on the official redhat site > mentions the use of 'sudo'. This isn't Red Hat's project, though. regards, john |
From: William C. <wc...@re...> - 2006-02-09 22:06:56
Attachments:
opcontrol_path.patch
|
John Levon wrote: > On Tue, Feb 07, 2006 at 03:59:23PM +0000, Lu=EDs Miguel Silva wrote: >=20 >=20 >>http://www.redhat.com/magazine/012oct05/features/oprofile/ >>http://devforums.amd.com/lofiversion/index.php/t359.html >>https://www.redhat.com/archives/fedora-devel-java-list/2005-March/msg00= 117.html >>https://uimon.cern.ch/twiki/bin/view/FIOgroup/LxbuildInfo >>http://prospect.sourceforge.net/ >=20 >=20 > I don't think we can be held responsible for what other people recommen= d. >=20 >=20 >>PS2: i dont really understand your agressive response. It is quite >>obvious that whoever did that opcontrol script tried to correct the >>security bug i mentioned by exporting a "safe" PATH on the >>script...(however...it should be about 2 lines sooner ;oP). >=20 >=20 > As I mentioned I'd welcome a patch to fix this particular problem. > However, no security audit has been done and I'm afraid I don't agree > that auditing a shell script is easy. This is why we won't recommend > using problematic features like sudo until somebody trustworthy does > this audit. >=20 > (And I suspect the audit would only make sense for the GUI, not the > shell script.) >=20 >=20 >>PS4: as you can see, even a article on the official redhat site >>mentions the use of 'sudo'. >=20 >=20 > This isn't Red Hat's project, though. >=20 > regards, > john Looking at the questionable line in opcontrol I realize why that was in=20 there in the first place. opcontrol needs to use oprofiled and ophelp.=20 If someone used --prefix and installed it in a non-standard place=20 another versions of ophelp and oprofiled might used. The script is=20 suppose to use the ophelp and oprofiled in the same directory as=20 opcontrol. Would having a full path to which and dirname be sufficient=20 to fix this problem like the attached patch? -Will |
From: John L. <le...@mo...> - 2006-02-09 22:25:24
|
On Thu, Feb 09, 2006 at 05:06:45PM -0500, William Cohen wrote: > Looking at the questionable line in opcontrol I realize why that was in > there in the first place. opcontrol needs to use oprofiled and ophelp. > If someone used --prefix and installed it in a non-standard place > another versions of ophelp and oprofiled might used. The script is > suppose to use the ophelp and oprofiled in the same directory as > opcontrol. Would having a full path to which and dirname be sufficient > to fix this problem like the attached patch? Patch is fine, but I don't want to give off the impression that we're supporting (broken configs of) sudo. regards john |
From: William C. <wc...@re...> - 2006-02-10 14:07:39
|
John Levon wrote: > On Thu, Feb 09, 2006 at 05:06:45PM -0500, William Cohen wrote: > > >>Looking at the questionable line in opcontrol I realize why that was in >>there in the first place. opcontrol needs to use oprofiled and ophelp. >>If someone used --prefix and installed it in a non-standard place >>another versions of ophelp and oprofiled might used. The script is >>suppose to use the ophelp and oprofiled in the same directory as >>opcontrol. Would having a full path to which and dirname be sufficient >>to fix this problem like the attached patch? > > > Patch is fine, but I don't want to give off the impression that we're > supporting (broken configs of) sudo. > > regards > john Yes, given that the opcontrol and other software has not been audited for security issues, using sudo shouldn't be avocated. I will check in the patch this morning. There have been a number of times that people have asked for performance monitoring capability configuration for normal users. Performance tools like Apple's Shark and sysprof allow normal users to use them. OProfile data analysis can be done by normal users, but it would really be nice to eliminate the root access. It doesn't have to allow fully flexible set up of OProfile configuration, allowing time-based monitoring of applications would be sufficient. -Will |
From: John L. <le...@mo...> - 2006-02-10 14:18:30
|
On Fri, Feb 10, 2006 at 09:07:34AM -0500, William Cohen wrote: > There have been a number of times that people have asked for performance > monitoring capability configuration for normal users. Performance tools > like Apple's Shark and sysprof allow normal users to use them. OProfile > data analysis can be done by normal users, but it would really be nice > to eliminate the root access. It doesn't have to allow fully flexible > set up of OProfile configuration, allowing time-based monitoring of > applications would be sufficient. Yes, it would. One way we might consider doing this is a restricted script that accepts no parameters (or at least validates them extremely carefully) then calls onto opcontrol. (Even then, we'd at least expect people to configure sudo properly). regards john |
From: M. S. <lm...@fe...> - 2006-02-09 23:28:41
|
Hello William! Yes, your patch would be sufficient! ;o) I was going to suggest having the "PATH=3D/usr/local/bin:/usr/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin" line before the invocation to the 'which'/'dirname' commands! Best, Lu=EDs Silva Quoting William Cohen <wc...@re...>: > John Levon wrote: >> On Tue, Feb 07, 2006 at 03:59:23PM +0000, Lu=EDs Miguel Silva wrote: >> >> >>> http://www.redhat.com/magazine/012oct05/features/oprofile/ >>> http://devforums.amd.com/lofiversion/index.php/t359.html >>> https://www.redhat.com/archives/fedora-devel-java-list/2005-March/msg00= 117.html >>> https://uimon.cern.ch/twiki/bin/view/FIOgroup/LxbuildInfo >>> http://prospect.sourceforge.net/ >> >> >> I don't think we can be held responsible for what other people recommend= . >> >> >>> PS2: i dont really understand your agressive response. It is quite >>> obvious that whoever did that opcontrol script tried to correct the >>> security bug i mentioned by exporting a "safe" PATH on the >>> script...(however...it should be about 2 lines sooner ;oP). >> >> >> As I mentioned I'd welcome a patch to fix this particular problem. >> However, no security audit has been done and I'm afraid I don't agree >> that auditing a shell script is easy. This is why we won't recommend >> using problematic features like sudo until somebody trustworthy does >> this audit. >> >> (And I suspect the audit would only make sense for the GUI, not the >> shell script.) >> >> >>> PS4: as you can see, even a article on the official redhat site >>> mentions the use of 'sudo'. >> >> >> This isn't Red Hat's project, though. >> >> regards, >> john > > Looking at the questionable line in opcontrol I realize why that was > in there in the first place. opcontrol needs to use oprofiled and > ophelp. If someone used --prefix and installed it in a non-standard > place another versions of ophelp and oprofiled might used. The script > is suppose to use the ophelp and oprofiled in the same directory as > opcontrol. Would having a full path to which and dirname be > sufficient to fix this problem like the attached patch? > > -Will > |