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

[Sean Hudson]

On 2017-06-19 09:05 AM, Mark Hatle wrote:
> 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.)

That sounds reasonable, although, TBH, if someone is adding credentials
to their SRC_URIs, I would expect that a best practice would be ignored.
 Perhaps adding a detection routine that emitted a warning during
parsing for credentials in the SRC_URI might be warranted?  Thoughts?

> 
> 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
>>
> 
> _______________________________________________
> Openembedded-architecture mailing list
> Openembedded-architecture at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
> 


-- 
Sean

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20170619/3cfc346b/attachment-0002.sig>