OE-Core/Yocto Project's first CVE (CVE-2017-9731)
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.
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
Quoted 7 lines · Richard Purdie
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.
Philip
Quoted 24 lines
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_URIbeing 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
Quoted 3 lines · Philip Balister
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.
Yes, SRC_URI can contain username/passwords, and even if you filter those out explicitly you can expose internal hostnames and so on.
Ross
Quoted 8 lines · Ross
Quoted 3 lines · Philip Balister
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.
Yes,
SRC_URIcan contain username/passwords, and even if you filter those out explicitly you can expose internal hostnames and so on.
But we do expose internal host names in other places ...
Philip
Quoted 3 lines
Ross
Quoted 11 lines · Philip Balister
Quoted 7 lines · Richard Purdie
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
Quoted 32 lines
Philip
Quoted 16 lines
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_URIbeing in the Source: field however I couldn't see any other realistic way forward.Quoted 8 lines
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
Quoted 31 lines · Mark Hatle
Quoted 11 lines · Philip Balister
Quoted 7 lines · Richard Purdie
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.
Quoted 4 lines
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?
Quoted 49 lines
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
Quoted 27 lines
Philip
Quoted 16 lines
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_URIbeing in the Source: field however I couldn't see any other realistic way forward.Quoted 8 lines
Cheers,
Richard
_______________________________________________
Openembedded-architecture mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-architectureQuoted 5 lines
_______________________________________________
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
Signature · 1 line
Sean
Quoted 10 lines · CEST Sean Hudson
Quoted 4 lines · Mark Hatle
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 theSRC_URImight be warranted? Thoughts?
This might be useful yes. I think the stumbling block is that at the moment we would have to have it off by default and then the user is almost certainly not going to know to turn it on. Perhaps this is another thing that we might check in a "production" vs. "development" mode where the user can easily switch to the former to enable a set of more stringent checks.
FWIW it's not quite the same thing but some of what you might want to do when moving to production is described in this section of the manual (which, full disclosure, I had a hand in writing):
http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#making-images-more-secure
Cheers,
Paul
Signature · 2 lines
Paul Eggleton Intel Open Source Technology Centre
Quoted 12 lines · Paul Eggleton
Quoted 10 lines · CEST Sean Hudson
Quoted 4 lines · Mark Hatle
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 theSRC_URImight be warranted? Thoughts?
Quoted 5 lines
This might be useful yes. I think the stumbling block is that at the moment we would have to have it off by default and then the user is almost certainly not going to know to turn it on. Perhaps this is another thing that we might check in a "production" vs. "development" mode where the user can easily switch to the former to enable a set of more stringent checks.
I'm not sure I follow. What would prevent us from turning on a warning that detected credentials in a SRC_URI by default? Even with Richard's change to prevent the information from propagating into the .ipk, it seems useful to notify the user. Personally, I'd like to know if one of the recipes I'm using has such information in it regardless of whether I'm generating a development or a production image.
Signature · 1 line
Sean
Quoted 20 lines · CEST you
Quoted 12 lines · Paul Eggleton
Quoted 10 lines · CEST Sean Hudson
Quoted 4 lines · Mark Hatle
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 theSRC_URImight be warranted? Thoughts?Quoted 6 lines
This might be useful yes. I think the stumbling block is that at the moment we would have to have it off by default and then the user is almost certainly not going to know to turn it on. Perhaps this is another thing that we might check in a "production" vs. "development" mode where the user can easily switch to the former to enable a set of more stringent checks.
Quoted 6 lines
I'm not sure I follow. What would prevent us from turning on a warning that detected credentials in a
SRC_URIby default? Even with Richard's change to prevent the information from propagating into the .ipk, it seems useful to notify the user. Personally, I'd like to know if one of the recipes I'm using has such information in it regardless of whether I'm generating a development or a production image.
You might, sure, but if you're in an environment where during development your source is on a server requiring such credentials then it's going to be a bit annoying to keep seeing that warning.
Anyway, there's certainly no harm in adding such a check, whether it's on by default or not is a separate issue.
Cheers,
Paul
Signature · 2 lines
Paul Eggleton Intel Open Source Technology Centre
Quoted 29 lines · Sean Hudson
Quoted 19 lines · Paul Eggleton
Quoted 10 lines · CEST Sean Hudson
Quoted 8 lines · Mark Hatle
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.)Quoted 7 lines
That sounds reasonable, although, TBH, if someone is adding credentials
to theirSRC_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 theSRC_URImight be warranted? Thoughts?Quoted 9 lines
This might be useful yes. I think the stumbling block is that at the moment we
would have to have it off by default and then the user is almost certainly not
going to know to turn it on. Perhaps this is another thing that we might check
in a "production" vs. "development" mode where the user can easily switch to
the former to enable a set of more stringent checks.
Quoted 6 lines
I'm not sure I follow. What would prevent us from turning on a warning that detected credentials in a
SRC_URIby default? Even with Richard's change to prevent the information from propagating into the .ipk, it seems useful to notify the user. Personally, I'd like to know if one of the recipes I'm using has such information in it regardless of whether I'm generating a development or a production image.
We can certainly do this, its technically not an issue. My worry is that if gives false security feelings since you can easily expose hostnames or other information as well as credentials. Where do we stop?
We could go as far as to stop bitbake supporting usernames/passwords in urls. There are some usecases where that is useful though...
Cheers,
Richard
Quoted 7 lines · Richard Purdie
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.
Does any of the 'archiver' output include copies/versions of the full SRC_URI? Same with the license management parts... (I don't think either do) but these would be the places I'd think the SRC_URI might also be.
--Mark
Quoted 23 lines
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_URIbeing 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
Hi all,
Sorry that the fix/workaround for this vulnerability was not discussed publically. This vulnerability was reported by a user privately/encrypted. Yocto Security team; Sona, Michael Halstead and Richard handled this off-list. We decided that we provide a quick fix/workaround before we make this vulnerability public and then change/ improve it later if necessary.
Quoted 2 lines
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.
We have received a CVE from Mitre for this vulnerability, but they have changed our description of vulnerability of some unknown reason :) we have requested an update/correction (see below) but they haven't changed the description yet:
From: CVE Request [mailto:[email protected]]
Sent: Monday, June 19, 2017 12:09 PM
To: Sona Sarmadi <[email protected]>
Subject: CVE Request 349461 for Update Published CVE
Thank you for your submission. It will be reviewed by a CVE Assignment Team member.
You have requested an update to the following published CVE: CVE-2017-9731
Changes, additions, or updates to your request can be sent to the CVE Team by replying directly to this email.
Please do not change the subject line, which allows us to effectively track your request.
CVE Assignment Team
M/S M300, 202 Burlington Road, Bedford, MA 01730 USA [A PGP key is available for encrypted communications at
http://cve.mitre.org/cve/request_id.html]
Thanks all for your help with this vulnerability.
//Sona
Quoted 16 lines · Richard Purdie
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.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.
Quoted 6 lines
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_URIbeing in the Source: field however I couldn't see any other realistic way forward.
I noticed that this wasn't CC'ed to the yocto-security mailing list. Was that just an oversight, or should that mailing list be considered defunct at this point?
Thanks,
Scott
Quoted 25 lines · Scott Murray
Quoted 23 lines · Richard Purdie
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.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.
Quoted 8 lines
Quoted 5 lines
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 onSRC_URIbeing in the Source: field however I couldn't see any other realistic way forward.I noticed that this wasn't CC'ed to the yocto-security mailing list. Was that just an oversight, or should that mailing list be considered defunct at this point?
Sorry, it was oversight...
Cheers,
Richard
Quoted 32 lines · Richard Purdie
Quoted 31 lines · Scott Murray
Quoted 28 lines · Richard Purdie
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.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 onSRC_URIbeing in the Source: field however I couldn't see any other realistic way forward.
Quoted 5 lines
Quoted 3 lines
I noticed that this wasn't CC'ed to the yocto-security mailing list. Was that just an oversight, or should that mailing list be considered defunct at this point?
Sorry, it was oversight...
Okay, good to know. IMO it might be worthwhile to post it there even if it's a bit late, just to set a precedent of that list providing such information, but it's your call.
Cheers,
Scott