[OE-core] [Openembedded-architecture] OE-Core/Yocto Project's first CVE (CVE-2017-9731)

[Mark Hatle]

On 6/19/17 8:20 AM, Philip Balister wrote:
> On 06/19/2017 06:38 AM, Richard Purdie wrote:
>> I suspect this has been missed by some people so I want to spell it
>> out. We have our first CVE in OE-Core itself.
>>
>> The issue is limited to binary ipks potentially exposing sensitive
>> information through the "Source:" field which contained the full
>> SRC_URI. Those urls could potentially contain sensitive information
>> about servers and credentials.
> 
> So the issue is leaking credentials, not build system paths? I mention
> this because we do leak build system paths into images in other places.

Build systems paths would be unrelated to this, assuming I understand it properly.

Information leak of the build user, time of build, and build system paths can
all occur.  (This is part of the overall binary reproducible stuff as well.)

When it comes to information leaks, specifically build system leaks.  As long as
they don't contain credential information then it is a point of mitigation vs a
'bug' in my opinion.  We clearly want to move toward a binary reproducible build
-- doing so will further limit the leaks (or at least make them understood.)

For build user, hostname, directories and build time/date issues -- we've
already mitigated many of them.  Directory structure was done when we started to
use the compilers path replacement operations.  (It's probably not 100%
effective, but I'd say any items that are left are reasonable bug candidates.)
We've also made passes to remove many of the other items, but I'd simply
consider them regular bugs at this point...  but information leaks like this are
something people often don't think about and probably should be made aware of.

It would be reasonable to write up a 'best practices' type document.  Explaining
that simply due to the nature of building many of these things will be 'leaked'
and where some of them are leaked through.  (Package generation, compilation,
etc for instance.)

Controlling your 'production' build environment can mitigate many of the
potential issues here.  By using non-confidential path names (i.e. don't include
confidential 'customer', code-name, etc in build paths), changing or otherwise
managing the host name on your build system (i.e. instead of
my-product.my-company.internal.com... something like 'build-1' as a hostname can
help hide many of these things.)  Using a 'build user' who doesn't have any
network credentials, other then on the build system itself...

--Mark

> Philip
> 
> 
>>
>> After discussion, I ended up changing the field to contain the recipe
>> filename (no path). There was talk of filtering the urls however if you
>> try, it becomes clear that sensitive elements can remain and no
>> solution is likely 100% effective. The other package backends don't do
>> this at all so this brings ipk more into line with them. Simply
>> clearing the field doesn't work with the current opkg-utils. It can be
>> changed but the change becomes more invasive.
>>
>> This fix has been merged to master.
>>
>> I also did take the decision to backport this change back to
>> pyro/morty/krogoth too. I appreciate this can cause some disruption to
>> people who rely on SRC_URI being in the Source: field however I
>> couldn't see any other realistic way forward.
>>
>> Cheers,
>>
>> Richard
>> _______________________________________________
>> Openembedded-architecture mailing list
>> Openembedded-architecture at lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
>>
> _______________________________________________
> Openembedded-architecture mailing list
> Openembedded-architecture at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
>