Message ID | 610f86be-79bb-451f-a9c1-6fcbdc78a2c9@gotplt.org |
---|---|
State | New |
Headers | show |
Series | SECURITY.txt: Drop "exploitable" in reference to hardening issues | expand |
On 2023-12-18 09:35, Siddhesh Poyarekar wrote: > The "exploitable vulnerability" may lead to a misunderstanding that > missed hardening issues are considered vulnerabilities, just that > they're not exploitable. This is not true, since while hardening bugs > may be security-relevant, the absence of hardening does not make a > program any more vulnerable to exploits than without. > > Drop the "exploitable" word to make it clear that missed hardening is > not considered a vulnerability. Ping, may I commit this if there are no objections? Thanks, Sid > > diff --git a/SECURITY.txt b/SECURITY.txt > index b3e2bbfda90..126603d4c22 100644 > --- a/SECURITY.txt > +++ b/SECURITY.txt > @@ -155,10 +155,10 @@ Security features implemented in GCC > GCC implements a number of security features that reduce the impact > of security issues in applications, such as -fstack-protector, > -fstack-clash-protection, _FORTIFY_SOURCE and so on. A failure of > - these features to function perfectly in all situations is not an > - exploitable vulnerability in itself since it does not affect the > - correctness of programs. Further, they're dependent on heuristics > - and may not always have full coverage for protection. > + these features to function perfectly in all situations is not a > + vulnerability in itself since it does not affect the correctness of > + programs. Further, they're dependent on heuristics and may not > + always have full coverage for protection. > > Similarly, GCC may transform code in a way that the correctness of > the expressed algorithm is preserved, but supplementary properties >
> Am 09.01.2024 um 16:13 schrieb Siddhesh Poyarekar <siddhesh@gotplt.org>: > > On 2023-12-18 09:35, Siddhesh Poyarekar wrote: >> The "exploitable vulnerability" may lead to a misunderstanding that missed hardening issues are considered vulnerabilities, just that they're not exploitable. This is not true, since while hardening bugs may be security-relevant, the absence of hardening does not make a program any more vulnerable to exploits than without. >> Drop the "exploitable" word to make it clear that missed hardening is not considered a vulnerability. > > Ping, may I commit this if there are no objections? Go ahead. Richard > Thanks, > Sid > >> diff --git a/SECURITY.txt b/SECURITY.txt >> index b3e2bbfda90..126603d4c22 100644 >> --- a/SECURITY.txt >> +++ b/SECURITY.txt >> @@ -155,10 +155,10 @@ Security features implemented in GCC >> GCC implements a number of security features that reduce the impact >> of security issues in applications, such as -fstack-protector, >> -fstack-clash-protection, _FORTIFY_SOURCE and so on. A failure of >> - these features to function perfectly in all situations is not an >> - exploitable vulnerability in itself since it does not affect the >> - correctness of programs. Further, they're dependent on heuristics >> - and may not always have full coverage for protection. >> + these features to function perfectly in all situations is not a >> + vulnerability in itself since it does not affect the correctness of >> + programs. Further, they're dependent on heuristics and may not >> + always have full coverage for protection. >> Similarly, GCC may transform code in a way that the correctness of >> the expressed algorithm is preserved, but supplementary properties
diff --git a/SECURITY.txt b/SECURITY.txt index b3e2bbfda90..126603d4c22 100644 --- a/SECURITY.txt +++ b/SECURITY.txt @@ -155,10 +155,10 @@ Security features implemented in GCC GCC implements a number of security features that reduce the impact of security issues in applications, such as -fstack-protector, -fstack-clash-protection, _FORTIFY_SOURCE and so on. A failure of - these features to function perfectly in all situations is not an - exploitable vulnerability in itself since it does not affect the - correctness of programs. Further, they're dependent on heuristics - and may not always have full coverage for protection. + these features to function perfectly in all situations is not a + vulnerability in itself since it does not affect the correctness of + programs. Further, they're dependent on heuristics and may not + always have full coverage for protection. Similarly, GCC may transform code in a way that the correctness of the expressed algorithm is preserved, but supplementary properties