[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d5b6cf123db60902d480129396d0a8fb@opensec.fr>
Date: Fri, 13 Nov 2015 09:04:08 +0100
From: HacKurx <hackurx@...il.com>
To: kernel-hardening@...ts.openwall.com
Subject: Re: Binary blobs
Le 2015-11-09 23:20, Valdis.Kletnieks@...edu a écrit :
> On Mon, 09 Nov 2015 22:59:31 +0100, HacKurx said:
>> The binary blobs are a potential for undetectable or irreparable
>> security flaws (Andrews Jeremy "Interview: Theo de Raadt",
>> KernelTrap).
>>
>> What is your point of view? Linux-libre kernel is the only reliable
>> basis?
>
> Closed source is by definition not easily examined for security issues
> (though
> once you get to monsters like LibreOffice or Firefox, even open source
> code
> is difficult to audit).
>
> The problem is that at the current time, not all software is easily
> opened. For
> example, the single biggest reason (among several) that NVidia has a
> binary
> blob driver is that (simplifying *drastically* here) when SGI's
> graphics
> division imploded, NVidia got all the engineers - but Microsoft snarfed
> up a
> bunch of patents connected to OpenGL. So NVidia had no realistic
> choice but to
> license the intellectual property from Microsoft.
>
> So out in the real world, you have to look at your threat model, and
> decide
> how paranoid you are. (Personally, I'd be more worried about the
> open-sourced
> Firefox code than I would the NVidia binary blob. The former has got a
> *huge*
> attack surface compared to the latter....)
Yes indeed. But for your information you can use Firefox with MPROTECT
and all hardened options for GCC.
http://hardenedgentoo.blogspot.fr/2012/02/firefox-1001-mprotect-strikes-again.html
Disable in firefox: methodjit, tracejit & ion. The performance remains
very good :)
Le 2015-11-10 00:33, Kees Cook a écrit :
> On Mon, Nov 9, 2015 at 2:20 PM, <Valdis.Kletnieks@...edu> wrote:
>> On Mon, 09 Nov 2015 22:59:31 +0100, HacKurx said:
>>> The binary blobs are a potential for undetectable or irreparable
>>> security flaws (Andrews Jeremy "Interview: Theo de Raadt",
>>> KernelTrap).
>>>
>>> What is your point of view? Linux-libre kernel is the only reliable
>>> basis?
>>
>> Closed source is by definition not easily examined for security issues
>> (though
>> once you get to monsters like LibreOffice or Firefox, even open source
>> code
>> is difficult to audit).
>>
>> The problem is that at the current time, not all software is easily
>> opened. For
>> example, the single biggest reason (among several) that NVidia has a
>> binary
>> blob driver is that (simplifying *drastically* here) when SGI's
>> graphics
>> division imploded, NVidia got all the engineers - but Microsoft
>> snarfed up a
>> bunch of patents connected to OpenGL. So NVidia had no realistic
>> choice but to
>> license the intellectual property from Microsoft.
>>
>> So out in the real world, you have to look at your threat model, and
>> decide
>> how paranoid you are. (Personally, I'd be more worried about the
>> open-sourced
>> Firefox code than I would the NVidia binary blob. The former has got
>> a *huge*
>> attack surface compared to the latter....)
>
> I think the first step is making sure you know _what_ blobs you're
> loading, and to have a known list of them. (There are efforts started
> with signed firmware[1] validation or the loadpin[2] LSM -- though
> neither yet deal with userspace loaded blobs like graphics drivers,
> SSD firmware, etc). This would block having blobs be manipulated
> maliciously before they're loaded. After that mechanism is in place,
> then it'd be useful to reverse engineer them to find security flaws.
>
> -Kees
>
> [1]
> http://lists.linuxfoundation.org/pipermail/ksummit-discuss/2015-August/002238.html
> [2]
> http://git.kernel.org/cgit/linux/kernel/git/kees/linux.git/log/?h=lsm/loadpin
Okay, thanks for the clarifications
--
Best regards,
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
