Full Disclosure mailing list archives
Re: Internet has vuln.
From: Justin Ferguson <jf () ownco net>
Date: Fri, 13 Sep 2013 15:07:17 -0400
Which "they" was it?
Here's the NSA signing off on the patch being added to libselinux.. At least on android https://android.googlesource.com/platform/external/libselinux/+/d2302ca4c4142f4b46df3d334288fb7f7f939ed2%5E%5E!/
In other words - under what conditions can you make a truncation to MAX_PATH cause an actual hole? And to count as "underhanded" rather than merely "buggy", you'd need at least a whiff of evidence that it was intentional.
Taking 30 seconds to read the code instead of broken english from some random developer and interpreting it to my preferred definition, basically in most instances it looks like selinux_mnt comes from a macro defined to either /selinux or in the /sys filesystem by default, however it's part of the exported API by libselinux, meaning that it's really not solvable question by looking only at the library, in its own no, if a 3rd party application uses it, then its possible. While it seems like its probably fine, they probably should be making sure that the selinux_mnt path + "/create" doesn't cause truncation for long paths, although tbf I'm not even positive what the linux kernel semantics for snprintf() are, as its not libc's and nothing says it has to behave in a given manner.
Or as Kohei replied to you:
Why on earth would you assume that the guy you're talking to (Steve Wray) is the guy the broken english dev replied to, whose name was apparently Jeffrey Walton.
The selinux_mnt is not a variable given by external one, unless application does not update it by itself. It is not difficult to modify this part to return ENAMETOOLONG when snprintf() returns larger or equal with PATH_MAX."
I like how you clipped the rest of his response there, making it appear that his justification supported your rationale, when in actuality he said: "its not just my code, if we fix it there we need to also fix it all over the library": "It is not difficult to modify this part to return ENAMETOOLONG when snprintf() returns larger or equal with PATH_MAX. But it is not only one point to fix libselinux, if we try." That all said, the very idea that the selinux policies would be the place where if anyone (whether it be NSA, FSB, et cetera) backdoored it, thats where it is at is absurd. That's something that could be statically tested approaching an assurance of 100% if not 100%. The code on the other hand, there's nothing, not even these fabled many eyes that prevent all sorts of bugs supposedly, can detect all of the bugs. A good example I'm fond of is the rumor about the FBI backdooring OpenBSDs ipsec stack, the entire interwebs descending on iked et al looking for bugs and similar, and missing this really blazingly simple one: http://openbsd.7691.n7.nabble.com/IKEv2-amp-openssl-td188397.html . Moreover, why the NSA would even need to backdoor the kernel is a little silly, the kernel dev's do a good enough job of backdooring it by accident with a myriad of eternal bugs, no subterfuge necessary. On Fri, Sep 13, 2013 at 2:45 PM, <Valdis.Kletnieks () vt edu> wrote:
On Thu, 12 Sep 2013 18:23:53 -0400, Jeffrey Walton said:They ignored my comments on fixed size arrays based on MAX_PATH and the subsequent overflows and silent truncations due to use of sprintf and snprintf....Which "they" was it? If you're referring to this: http://comments.gmane.org/gmane.comp.security.selinux/16844 Note that the guy you were replying to was a Japanese software engineer employed by NEC. If you want to argue the guy was an NSA plant trying to get a backdoor in, feel free. But don't expect to be taken seriously without some additional evidence. And it counted as "underhanded", how, exactly? In other words - under what conditions can you make a truncation to MAX_PATH cause an actual hole? And to count as "underhanded" rather than merely "buggy", you'd need at least a whiff of evidence that it was intentional. Or as Kohei replied to you: "The selinux_mnt is not a variable given by external one, unless application does not update it by itself. It is not difficult to modify this part to return ENAMETOOLONG when snprintf() returns larger or equal with PATH_MAX." In the Linux community, this would count as '-ENOPATCH', as I'm not finding where you ever submitted a patch to fix the issue. _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Current thread:
- Internet has vuln. coderman (Sep 06)
- Re: Internet has vuln. coderman (Sep 11)
- Re: Internet has vuln. coderman (Sep 11)
- Re: Internet has vuln. Steve Wray (Sep 12)
- Re: Internet has vuln. coderman (Sep 12)
- Re: Internet has vuln. coderman (Sep 12)
- Re: Internet has vuln. Valdis . Kletnieks (Sep 12)
- Re: Internet has vuln. Jeffrey Walton (Sep 12)
- Re: Internet has vuln. Valdis . Kletnieks (Sep 13)
- Re: Internet has vuln. Justin Ferguson (Sep 13)
- Re: Internet has vuln. Jeffrey Walton (Sep 13)
- Re: Internet has vuln. Justin Ferguson (Sep 13)
- Re: Internet has vuln. coderman (Sep 11)
- Re: Internet has vuln. coderman (Sep 11)
- Re: Internet has vuln. Tracy Reed (Sep 13)
- Re: Internet has vuln. Steve Wray (Sep 14)