Message-ID: <CAG-zyRw_u4pcj_sELaOm3w18H6W+Snm-fnGpArWe+CdWPwviaA@mail.gmail.com>
Date: Fri, 13 Sep 2013 15:07:17 -0400
From: Justin Ferguson <jf@...co.net>
To: Valdis.Kletnieks@...edu
Cc: full-disclosure <full-disclosure@...ts.grok.org.uk>,
 Steve Wray <stevedwray@...il.com>
Subject: Re: Internet has vuln.

> 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@...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/

Powered by blists - more mailing lists