New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NEWS: added mention of CVE-2017-9445 fix #6225

Closed
wants to merge 1 commit into
base: master
from

Conversation

8 participants
@shibumi
Contributor

shibumi commented Jun 28, 2017

Hello,
The fix was so difficult to find because no issue mentions the CVE number. Therefore I have included the fix in the NEWS file. I hope this will safe some time for others who search for it.
The associated issue is: #6214

Christian Rebischke Christian Rebischke
@poettering

This comment has been minimized.

Show comment
Hide comment
@poettering

poettering Jun 28, 2017

Member

Humpf, I am not convinced this is the right way to announce this. We never did that, and half the CVEs aren't useful anyway, hence I am not sure we should start with that now, because it is either inherently incomplete or blesses the nonsensical part of the CVE circus which we really shouldn't bless...

Member

poettering commented Jun 28, 2017

Humpf, I am not convinced this is the right way to announce this. We never did that, and half the CVEs aren't useful anyway, hence I am not sure we should start with that now, because it is either inherently incomplete or blesses the nonsensical part of the CVE circus which we really shouldn't bless...

@shibumi

This comment has been minimized.

Show comment
Hide comment
@shibumi

shibumi Jun 28, 2017

Contributor

Well it would make it for security teams a lot easier to search for CVE fixes in systemd if you would mention them in NEWS or some other file and in your issues. I understand that you don't want to feed the trolls with CVEs, but it would make the work of security teams more efficient. Definitely something to think about it.

Contributor

shibumi commented Jun 28, 2017

Well it would make it for security teams a lot easier to search for CVE fixes in systemd if you would mention them in NEWS or some other file and in your issues. I understand that you don't want to feed the trolls with CVEs, but it would make the work of security teams more efficient. Definitely something to think about it.

@nfoonf

This comment has been minimized.

Show comment
Hide comment
@nfoonf

nfoonf Jun 28, 2017

Oh yes please. I worked for one of the German CERTs for seven years. CVEs can not be valued high enough if you if you have to research vuln info for risk assesments or helping some admins in your constituency recovering from an incident. CVEs and CVSS Scores are far from perfect, but often the only thing to start from.

nfoonf commented Jun 28, 2017

Oh yes please. I worked for one of the German CERTs for seven years. CVEs can not be valued high enough if you if you have to research vuln info for risk assesments or helping some admins in your constituency recovering from an incident. CVEs and CVSS Scores are far from perfect, but often the only thing to start from.

@danimo

This comment has been minimized.

Show comment
Hide comment
@danimo

danimo Jun 29, 2017

Contributor

Just roll with documenting CVEs. It does make life easier for everyone down the stream.

Contributor

danimo commented Jun 29, 2017

Just roll with documenting CVEs. It does make life easier for everyone down the stream.

@eranmes

This comment has been minimized.

Show comment
Hide comment
@eranmes

eranmes Jun 29, 2017

Re @poettering 's comments about half the CVEs not being useful, if the argument is that it is uninformative to include references to them because they seem minor or irrelevant, then I'll point out that what seems minor to one could be an essential link in a chain of vulnerabilities abused by an attacker to compromise a system.

eranmes commented Jun 29, 2017

Re @poettering 's comments about half the CVEs not being useful, if the argument is that it is uninformative to include references to them because they seem minor or irrelevant, then I'll point out that what seems minor to one could be an essential link in a chain of vulnerabilities abused by an attacker to compromise a system.

@evverx

This comment has been minimized.

Show comment
Hide comment
@evverx

evverx Jun 29, 2017

Member

The CVE ID has been mentioned in the commit message, so either

git log --grep=CVE-2017-9445

or https://github.com/systemd/systemd/search?utf8=✓&q=CVE-2017-9445 might be used to find the fix.

I hope this will safe some time for others who search for it

I'm not sure I understand how this PR will simplify the search. Could you elaborate on this?

Member

evverx commented Jun 29, 2017

The CVE ID has been mentioned in the commit message, so either

git log --grep=CVE-2017-9445

or https://github.com/systemd/systemd/search?utf8=✓&q=CVE-2017-9445 might be used to find the fix.

I hope this will safe some time for others who search for it

I'm not sure I understand how this PR will simplify the search. Could you elaborate on this?

@shibumi

This comment has been minimized.

Show comment
Hide comment
@shibumi

shibumi Jun 29, 2017

Contributor

Would still be cool to have a quick overview in the NEWS file when were which CVE solved. It's a lot of work to search for every CVE through the commits and check which version was released after this CVE.
It's even not much work. Just include the CVE number in the NEWS file or in a seperate SECURITY file or whatever with a small description about the CVE. Nobody would lose something, everybody would win.

Contributor

shibumi commented Jun 29, 2017

Would still be cool to have a quick overview in the NEWS file when were which CVE solved. It's a lot of work to search for every CVE through the commits and check which version was released after this CVE.
It's even not much work. Just include the CVE number in the NEWS file or in a seperate SECURITY file or whatever with a small description about the CVE. Nobody would lose something, everybody would win.

@IPv4v6

This comment has been minimized.

Show comment
Hide comment
@IPv4v6

IPv4v6 Jun 29, 2017

Contributor

@evverx when downloading a source tarball I have no possibility to do a "git log".

Other projects document security vulnerabilities in a file for easy reference.
See here: https://github.com/samba-team/samba/blob/samba-4.6.5/WHATSNEW.txt#L300

@poettering why do you think half of the CVEs aren't useful?

Contributor

IPv4v6 commented Jun 29, 2017

@evverx when downloading a source tarball I have no possibility to do a "git log".

Other projects document security vulnerabilities in a file for easy reference.
See here: https://github.com/samba-team/samba/blob/samba-4.6.5/WHATSNEW.txt#L300

@poettering why do you think half of the CVEs aren't useful?

@evverx

This comment has been minimized.

Show comment
Hide comment
@evverx

evverx Jun 30, 2017

Member

After I had read the sentence

The fix was so difficult to find because no issue mentions the CVE number.

, I thought that the issue was about finding the patch which can be applied to fix the vulnerability, and downloading a source tarball or reading the NEWS file doesn't seem to be the best way to deal with that.

Would still be cool to have a quick overview in the NEWS file when were which CVE solved.
Other projects document security vulnerabilities in a file for easy reference.

I understand why some projects do that, but I don't think I understand why everybody should do the same. Why do you think this is useful?

Member

evverx commented Jun 30, 2017

After I had read the sentence

The fix was so difficult to find because no issue mentions the CVE number.

, I thought that the issue was about finding the patch which can be applied to fix the vulnerability, and downloading a source tarball or reading the NEWS file doesn't seem to be the best way to deal with that.

Would still be cool to have a quick overview in the NEWS file when were which CVE solved.
Other projects document security vulnerabilities in a file for easy reference.

I understand why some projects do that, but I don't think I understand why everybody should do the same. Why do you think this is useful?

@ebourg

This comment has been minimized.

Show comment
Hide comment
@ebourg

ebourg Jun 30, 2017

For the reference, here is how Apache Tomcat documents its security issues:

https://tomcat.apache.org/security-8.html

A dedicated page detailing the vulnerabilities fixed in each version and a link to the relevant commits.

ebourg commented Jun 30, 2017

For the reference, here is how Apache Tomcat documents its security issues:

https://tomcat.apache.org/security-8.html

A dedicated page detailing the vulnerabilities fixed in each version and a link to the relevant commits.

@evverx

This comment has been minimized.

Show comment
Hide comment
@evverx

evverx Jun 30, 2017

Member

Thank you for the link. The documentation looks really great. But it is slightly different from adding CVE IDs to the NEWS file and it also requires much more work than

It's even not much work. Just include the CVE number in the NEWS file or in a seperate SECURITY file or whatever with a small description about the CVE. Nobody would lose something, everybody would win.

Member

evverx commented Jun 30, 2017

Thank you for the link. The documentation looks really great. But it is slightly different from adding CVE IDs to the NEWS file and it also requires much more work than

It's even not much work. Just include the CVE number in the NEWS file or in a seperate SECURITY file or whatever with a small description about the CVE. Nobody would lose something, everybody would win.

@shibumi

This comment has been minimized.

Show comment
Hide comment
@shibumi

shibumi Jul 2, 2017

Contributor

@evverx if additional work is the problem I could help out with monitoring the CVEs. (I do this already for Arch linux).

Contributor

shibumi commented Jul 2, 2017

@evverx if additional work is the problem I could help out with monitoring the CVEs. (I do this already for Arch linux).

@evverx

This comment has been minimized.

Show comment
Hide comment
@evverx

evverx Jul 5, 2017

Member

@shibumi , thanks for your willingness to help. Apache Tomcat appears to have a security team which seems to follow some security policy and https://tomcat.apache.org/security-8.html is the result of that. I still don't understand how copying the result of some process fixes the lack of the process, but If listing CVEs in the README file makes people feel safer, I don't see the reason why this can't be done.

Member

evverx commented Jul 5, 2017

@shibumi , thanks for your willingness to help. Apache Tomcat appears to have a security team which seems to follow some security policy and https://tomcat.apache.org/security-8.html is the result of that. I still don't understand how copying the result of some process fixes the lack of the process, but If listing CVEs in the README file makes people feel safer, I don't see the reason why this can't be done.

@shibumi

This comment has been minimized.

Show comment
Hide comment
@shibumi

shibumi Jul 5, 2017

Contributor

@evverx I am unsure if we should pollute the README with it. We should better have an own SECURITY file for the CVEs + details. Except you just want to mention the fix, then it would be ok to have it in the NEWS-file or changelog.

Contributor

shibumi commented Jul 5, 2017

@evverx I am unsure if we should pollute the README with it. We should better have an own SECURITY file for the CVEs + details. Except you just want to mention the fix, then it would be ok to have it in the NEWS-file or changelog.

@poettering

This comment has been minimized.

Show comment
Hide comment
@poettering

poettering Jul 10, 2017

Member

I am not entirely sure what the big benefit of this would even be. I mean security simply doesn't work this way. If people wait with their system updates until we roll a release every now and then and announce them with a NEWS file and everything, then your security is very broken. Security is a constant process, and there is other infrastructure in place to propagate fixes in a high-frequency mode, outside of our low-frequentcy release cycles, and that's good that way, and the way it should be.

We used to use "git note" for tagging commits that fix security bugs, but stopped doing that, due to lack of interest ultimately from the supposed users of this data. And I am very sure including CVE docs in our NEWS would be any better, but in fact even worse...

Or to say this differently: if you roll your own distro, then you are doing things wrong if you wait for our NEWS announcement to do proper security.

Member

poettering commented Jul 10, 2017

I am not entirely sure what the big benefit of this would even be. I mean security simply doesn't work this way. If people wait with their system updates until we roll a release every now and then and announce them with a NEWS file and everything, then your security is very broken. Security is a constant process, and there is other infrastructure in place to propagate fixes in a high-frequency mode, outside of our low-frequentcy release cycles, and that's good that way, and the way it should be.

We used to use "git note" for tagging commits that fix security bugs, but stopped doing that, due to lack of interest ultimately from the supposed users of this data. And I am very sure including CVE docs in our NEWS would be any better, but in fact even worse...

Or to say this differently: if you roll your own distro, then you are doing things wrong if you wait for our NEWS announcement to do proper security.

@nfoonf

This comment has been minimized.

Show comment
Hide comment
@nfoonf

nfoonf Jul 10, 2017

Hi Lennart,

the Benefit of the CVE-Process is, that it makes securing Systems more manageable for normal admins out there. I can actually manage Security by having handle (the CVE-IDs) which also enables me to categorize Security-Risks which makes day-to-day live easier. For example, I probably don't need to patch a Vuln right away, when the possible Attack-Vector is implausible for my setup, but nonetheless I know about this vuln and come back to fixing it later, when it is more convenient. There are Tools and Websites around that support me in this tasks. You must think here about the average guy doing ops somewhere not highly specialized IT-Sec Professionals.

nfoonf commented Jul 10, 2017

Hi Lennart,

the Benefit of the CVE-Process is, that it makes securing Systems more manageable for normal admins out there. I can actually manage Security by having handle (the CVE-IDs) which also enables me to categorize Security-Risks which makes day-to-day live easier. For example, I probably don't need to patch a Vuln right away, when the possible Attack-Vector is implausible for my setup, but nonetheless I know about this vuln and come back to fixing it later, when it is more convenient. There are Tools and Websites around that support me in this tasks. You must think here about the average guy doing ops somewhere not highly specialized IT-Sec Professionals.

@shibumi

This comment has been minimized.

Show comment
Hide comment
@shibumi

shibumi Jul 12, 2017

Contributor

Hi Lennart,
Well I wouldn't use the NEWS file for such a documentation. What about a new SECURITY file. This file could contain all past CVEs of systemd + version in which they have been fixed (for documentation purpose). It wouldn't be more work for you or your devs. I would just edit this PR and would make this happen.

I understand your attitude, but @nfoonf is right. Having such a documentation would make dealing with systemd for a lot of people easier. People wouldn't need to search through commit messages and would have one file that gives a quick overview over current or past vulnerabilities in systemd.

Contributor

shibumi commented Jul 12, 2017

Hi Lennart,
Well I wouldn't use the NEWS file for such a documentation. What about a new SECURITY file. This file could contain all past CVEs of systemd + version in which they have been fixed (for documentation purpose). It wouldn't be more work for you or your devs. I would just edit this PR and would make this happen.

I understand your attitude, but @nfoonf is right. Having such a documentation would make dealing with systemd for a lot of people easier. People wouldn't need to search through commit messages and would have one file that gives a quick overview over current or past vulnerabilities in systemd.

@poettering

This comment has been minimized.

Show comment
Hide comment
@poettering

poettering Jul 13, 2017

Member

So, I will close this now. After the latest stunt the CVE folks pulled I am not convinced we should really carry the CVE information in our documentation. It's fine that the CVE organization does what they do, but I don't think we need to replicate their data here, in particular as the quality of the CVE reports is so varying. Yes, there's good information in CVE reports, but I am really not keen on blessing CVE-2017-1000082 and things like that, it's noise, and probably political. And that really just makes me not want to participate in this game. We have to deal with enough bureaucracy as it is, we don't need more, and we don't need the constant source of tension this creates.

Other than that, I also think the NEWS file in the git repo is simply the wrong place for this data, in particular as document we are supposed to update every release. Security doesn't work that way. We currently do a release every 4month. If you wait 4month for your security fixes, until we tell you about it in this document then you are simply doing security wrong. Security is a constant process, and whole companies have as business model to give you a constant high-frequency stream of fixes.

Also note that systemd doesn't exist in a vacuum, a Linux system consists of many packages, and hence I think it's definitely a better idea to watch the CVE database for systemd CVEs (along with your other packages) rather than watch systemd for CVEs we announce.

Anyway, I am not going to fight CVEs, I just don't think we need to do more in that area. There is plenty of infrastructure around for this, businesses, databases, services, infrastructure, everything, we do not need to replicate this here.

I am not against people tracking this somewhere, but I am not sure this has to be done as part of the systemd project, let alone the git tree.

Or to say this differently, you are welcome to stick this into some wiki or so, it's great if you do, but our NEWS or our git tree are really the wrong place.

Sorry, and thank you for understanding.

Member

poettering commented Jul 13, 2017

So, I will close this now. After the latest stunt the CVE folks pulled I am not convinced we should really carry the CVE information in our documentation. It's fine that the CVE organization does what they do, but I don't think we need to replicate their data here, in particular as the quality of the CVE reports is so varying. Yes, there's good information in CVE reports, but I am really not keen on blessing CVE-2017-1000082 and things like that, it's noise, and probably political. And that really just makes me not want to participate in this game. We have to deal with enough bureaucracy as it is, we don't need more, and we don't need the constant source of tension this creates.

Other than that, I also think the NEWS file in the git repo is simply the wrong place for this data, in particular as document we are supposed to update every release. Security doesn't work that way. We currently do a release every 4month. If you wait 4month for your security fixes, until we tell you about it in this document then you are simply doing security wrong. Security is a constant process, and whole companies have as business model to give you a constant high-frequency stream of fixes.

Also note that systemd doesn't exist in a vacuum, a Linux system consists of many packages, and hence I think it's definitely a better idea to watch the CVE database for systemd CVEs (along with your other packages) rather than watch systemd for CVEs we announce.

Anyway, I am not going to fight CVEs, I just don't think we need to do more in that area. There is plenty of infrastructure around for this, businesses, databases, services, infrastructure, everything, we do not need to replicate this here.

I am not against people tracking this somewhere, but I am not sure this has to be done as part of the systemd project, let alone the git tree.

Or to say this differently, you are welcome to stick this into some wiki or so, it's great if you do, but our NEWS or our git tree are really the wrong place.

Sorry, and thank you for understanding.

@poettering poettering closed this Jul 13, 2017

@shibumi

This comment has been minimized.

Show comment
Hide comment
@shibumi

shibumi Jul 13, 2017

Contributor

sad, but thanks for the clear answer and your work on systemd. I have great respect for it.

Contributor

shibumi commented Jul 13, 2017

sad, but thanks for the clear answer and your work on systemd. I have great respect for it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment