tag:blogger.com,1999:blog-3287592806320436583.post3452426669999238885..comments2019-03-16T07:37:19.229-07:00Comments on Tavis Ormandy: Security Debianismstavisohttp://www.blogger.com/profile/15823607850344092370noreply@blogger.comBlogger18125tag:blogger.com,1999:blog-3287592806320436583.post-67864065907957617012013-08-26T12:19:16.510-07:002013-08-26T12:19:16.510-07:00@taviso Both tricks are bash-specific. Do you have...@taviso Both tricks are bash-specific. Do you have similar tricks for dash (current Debian/Ubuntu sh replacement)?<br /><br />I didn't research it but maybe an absolute path would have indeed prevented exploitation in Debian/Ubuntu.RoMaNSoFthttps://www.blogger.com/profile/15516592550449333336noreply@blogger.comtag:blogger.com,1999:blog-3287592806320436583.post-80590404670348104172013-08-24T10:07:32.299-07:002013-08-24T10:07:32.299-07:00@romansoft Actually, using a full path wouldn'...@romansoft Actually, using a full path wouldn't fix the problem, a classic exploit in that case would be something like this:<br /><br />$ env -i SHELLOPTS=xtrace PS4='$(id)' /bin/sh -c '/bin/true'<br />uid=1000<br /><br />Or exporting a function called '/bin/bar' (Yes, you can do that in bash).<br /><br />$ function /bin/true(){ id; }<br />$ export -f /bin/true<br />$ sh -c '/bin/true'<br />uid=1000<br /><br />It's almost impossible to use system() or popen() safely in a setuid program, which is why privmode is such a good idea!<br /><br />@kanotix You mean in my C program? I'm already three levels deep in shells at that point, privileges would have been dropped long ago and unfortunately you cannot get them back.<br /><br />system("foo")->/bin/sh -c "foo"->system("sh")->/bin/sh -c "sh"->/bin/sh<br /><br />You can see adding a -p to the last sh would not change anything, because the two earlier invocations do not have it.tavisohttps://www.blogger.com/profile/15823607850344092370noreply@blogger.comtag:blogger.com,1999:blog-3287592806320436583.post-75905157970890274352013-08-24T08:50:47.222-07:002013-08-24T08:50:47.222-07:00I see no huge problem to change "sh" to ...I see no huge problem to change "sh" to "bash -p" or to "sh -p" on other systems in your lsb-release override. Did you try that?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3287592806320436583.post-80239869354079484522013-08-24T02:03:24.295-07:002013-08-24T02:03:24.295-07:00All people seems to forget the golden rule: always...All people seems to forget the golden rule: always set up a trusted PATH (or use absolute path) before invoking a shell command with privileges.<br /><br />Of course, I'd prefer to drop privileges instead (more secure) or both (paranoid mode).<br /><br />Given said that, although Debian did bad by (unpurposedly) disabling a mitigation, the real vulnerability is clearly Vmware's fault.RoMaNSoFthttps://www.blogger.com/profile/15516592550449333336noreply@blogger.comtag:blogger.com,1999:blog-3287592806320436583.post-59630033970838243432013-08-23T22:36:34.396-07:002013-08-23T22:36:34.396-07:00Wait, no, I'm reading that entirely the wrong ...Wait, no, I'm reading that entirely the wrong way around, aren't I - it'll drop privileged mode if it's running as bash, but not if it's running as sh. I'm sorry, I'm a fool.Matthew Garretthttps://www.blogger.com/profile/10476767032912504787noreply@blogger.comtag:blogger.com,1999:blog-3287592806320436583.post-85392262003023082842013-08-23T19:47:34.987-07:002013-08-23T19:47:34.987-07:00The bash patch appears to do nothing if bash is ca...The bash patch appears to do nothing if bash is called as /bin/sh, which should mean it only causes problems if the code explicitly calls bash rather than calling system(). The security problem seems to be with using dash as /bin/sh, not the bash patch.Matthew Garretthttps://www.blogger.com/profile/10476767032912504787noreply@blogger.comtag:blogger.com,1999:blog-3287592806320436583.post-37241660763606472992013-08-23T18:51:35.680-07:002013-08-23T18:51:35.680-07:00Is this a possible back door into Debian? Why or ...Is this a possible back door into Debian? Why or why not? ThanksCharles Ghttps://www.blogger.com/profile/11372501328947308065noreply@blogger.comtag:blogger.com,1999:blog-3287592806320436583.post-45429523668657933082013-08-23T18:51:07.907-07:002013-08-23T18:51:07.907-07:00Is this a possible back door into Debian? Why or ...Is this a possible back door into Debian? Why or why not? ThanksCharles Ghttps://www.blogger.com/profile/11372501328947308065noreply@blogger.comtag:blogger.com,1999:blog-3287592806320436583.post-24307141015470315692013-08-23T18:44:02.771-07:002013-08-23T18:44:02.771-07:00This comment has been removed by the author.Charles Ghttps://www.blogger.com/profile/11372501328947308065noreply@blogger.comtag:blogger.com,1999:blog-3287592806320436583.post-27002949575521622102013-08-23T10:05:54.229-07:002013-08-23T10:05:54.229-07:00@openid: Thanks for taking a look. I realize this ...@openid: Thanks for taking a look. I realize this exploit has no real-world impact, that's why I never said anything (and the port was abandoned at the time.) I was more wondering if Tavis' thoughts on dropping privs apply here, because this seems to be the same idea. I had trouble with the shell dropping privs too, that's why I took the two-step approach with creating another suid binary. But maybe I was just being silly.vitalyhttps://www.blogger.com/profile/14203087242574468911noreply@blogger.comtag:blogger.com,1999:blog-3287592806320436583.post-19397113463359069672013-08-23T07:01:28.513-07:002013-08-23T07:01:28.513-07:00I'd just like to add that I use UUCP. Yes, in ...I'd just like to add that I use UUCP. Yes, in 2013. In fact, I set it up last year. At IBM. Because reasons.mathewhttps://www.blogger.com/profile/12934631957033086256noreply@blogger.comtag:blogger.com,1999:blog-3287592806320436583.post-2434237173588245762013-08-23T03:45:09.788-07:002013-08-23T03:45:09.788-07:00Debian is not primarily responsible, there's h...Debian is not primarily responsible, there's hundreds of shells out there and any one could have tickled this bug in VMware's software.<br /><br />Don't use system() or popen() in setuid programs, or in any other programs with more privileges than anyone who could have some control over the string being executed or your environment. Setuid is just one possible attack case. Fork and exec stuff yourself. It's not hard. VMware depended on a mitigating strategy that some shells implement, but it's not safe to depend on that mitigating strategies to save you from your own stupidity.<br /><br />(frankly, I would say don't use popen() or system() at all, but I gave up fighting THAT fight back in the '80s)Resunahttps://www.blogger.com/profile/11926139083455275005noreply@blogger.comtag:blogger.com,1999:blog-3287592806320436583.post-59163268273633902752013-08-23T01:22:40.520-07:002013-08-23T01:22:40.520-07:00Nevermind, htop on Linux doesn't seem to be +s...Nevermind, htop on Linux doesn't seem to be +s root, and as such isn't vulnerable.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3287592806320436583.post-84076786013616714972013-08-23T01:08:45.004-07:002013-08-23T01:08:45.004-07:00@vitaly: Your exploit does no longer work against ...@vitaly: Your exploit does no longer work against MacPorts' current htop, since it correctly executes /usr/bin/dtruss.<br /><br />However, upstream htop seems to be perfectly vulnerable to that: http://sourceforge.net/p/htop/code/308/tree/trunk/TraceScreen.c#l92.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3287592806320436583.post-9806114581979538982013-08-22T23:51:37.556-07:002013-08-22T23:51:37.556-07:00I guess this is the case on OS X as well? I wrote ...I guess this is the case on OS X as well? I wrote a lame 'exploit' for MacPorts htop in much the same vein a while back for fun: http://pastebin.com/sWv5bSXv. (Homebrew doesn't make htop +s root, and it's OS X, so I figure no one cares about actual vuln.)vitalyhttps://www.blogger.com/profile/14203087242574468911noreply@blogger.comtag:blogger.com,1999:blog-3287592806320436583.post-62439784811733222302013-08-22T23:35:14.201-07:002013-08-22T23:35:14.201-07:00I agree that VMware should be dropping privileges....I agree that VMware should be dropping privileges. lsb_release doesn't require root by any means.jduckhttps://www.blogger.com/profile/08277186239477077950noreply@blogger.comtag:blogger.com,1999:blog-3287592806320436583.post-29526148484719370802013-08-22T15:26:42.057-07:002013-08-22T15:26:42.057-07:00@Enno:
system() will fork and use /bin/sh to exec...@Enno:<br /><br />system() will fork and use /bin/sh to execute the binary. Which is why /bin/sh needs to drop privileges early.<br /><br />Look at the bash NOTES (section 7) that Tavis mentioned:<br /><br />"This means, among other things, that setuid or setgid programs which call system(3) (a horrendously bad practice in any case) relinquish their setuid/setgid status in the <b>child that's forked to execute /bin/sh</b>."Sigihttps://www.blogger.com/profile/13560728705152464043noreply@blogger.comtag:blogger.com,1999:blog-3287592806320436583.post-16126614737472499742013-08-22T15:09:30.160-07:002013-08-22T15:09:30.160-07:00Why doesn't VMware drop the permission before ...Why doesn't VMware drop the permission before calling out to lsb_release? Once you can place a binary by that name on the target system and it gets called with root permissions, I figure you've already won. It doesn't take sh to do that.Ennohttps://www.blogger.com/profile/05809329423417848910noreply@blogger.com