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 >>> [email protected] >>> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture >>> >> _______________________________________________ >> Openembedded-architecture mailing list >> [email protected] >> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture >> > > _______________________________________________ > Openembedded-architecture mailing list > [email protected] > http://lists.openembedded.org/mailman/listinfo/openembedded-architecture > -- Sean
signature.asc
Description: OpenPGP digital signature
-- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
