daniel:// stenberg://

Looking back at all (now) published vulnerabilities in #curl that were present in code from 2020 until now, at no point in those years was the share of "C mistakes" higher than 15% of all vulns.

Through all years, the C mistake share of all vulnerabilities in #curl was never above 45% at any single point in history.

Mar 7 at 9:48pmWeb
Show threaddaniel:// stenberg://Mar 7
we have three more CVEs pending that soon will expand this graph a little, but none of those is a C mistake...
Show threadChristoff, the humanMar 8
@bagder I'm assume every time folks pipe up about hur dur c is insecure, RIGHT EVERYONE?! show up?
Show threadcactusdualcoreMar 8

@christoff @bagder I think a lot of enterprise code is written with much less care about its quality. This enables C bugs. I don't think - even with unsafe - Rust can solve developer incompetence and laziness, and its longer and more thorough development will actually hinder adoption in areas that require rapid development.

Hopefully software practices in general improve :)

Show threadJake HowardMar 7
@bagder What changed ~2018? That's a pretty steep decline in C-related vulnerabilities.
Show threaddaniel:// stenberg://Mar 7
@jake I can't say or spot any specific change or process we did that could explain that...
Show threadPoliorceticsMar 7

@bagder @jake pure guess, maybe vulns in curl take years to discover (especially as software engineering techniques improve and make them harder to write in the first place) so we’re not yet seeing the « latest » vulns, only the old ones ?

It should be fairly easy to disprove though, @bagder do you have data on how long vuln stay in curl on average/median ?

Show threaddaniel:// stenberg://Mar 7
@poliorcetics @jake that's entirely true. Vulns in curl are 8 years old on average when reported! But also: there's no particular age difference between found vulns if they are C mistakes or not, so there's nothing that says they will change a lot. But we don't know...
Show threadAndrea (Drea) Tamar PinskiMar 7
@jake @bagder
There is also a jump after 2012 till 2018 for 'c mistakes'. That is definitely related to better tooling. E.g. sanitizers (which came out in 2012).
Also as you find the 'C mistakes' ones; there are less of them. And with folks running now with sanitizers on a daily bases, you will find them earlier. Not just about curl project doing it but folks in general.
Show threaddaniel:// stenberg://Mar 7
@pinskia @jake yes, the tooling has improved through-out all this time. Also: CI started to become a big thing in the 2015-2020 time-frame and OSS-fuzz started fuzzing curl in 2017
Show threadspinnyspinlockMar 7
@bagder do you have in mind some interesting or unexpected C ones? only for my curiosity/learning, nothing serious
Show threaddaniel:// stenberg://Mar 7
@spinnyspinlock we've only had two severity HIGH CVEs in #curl within the last five years, both of them were C mistakes: https://curl.se/docs/CVE-2023-38545.html and https://curl.se/docs/CVE-2021-22901.html
curl - SOCKS5 heap buffer overflow - CVE-2023-38545

Show threadspinnyspinlockMar 7
@bagder CVE-2021-22901 was exactly the kind of interesting vulnerability I wanted to see, thank you! well done on the good security track record too :)
Show threadChristian HuitemaMar 7
@spinnyspinlock @bagder Sanitizers are only as good as code coverage. If code is not exercised when the sanitizer runs, the bug will not be detected.
Show threadMartin UeckerMar 8
@huitema @spinnyspinlock @bagder What I started to do experimentally is use the sanitizers to insert traps and then see if that the optimizer removes the check. This can be used to prove that certain properties (covered by certain sanitizers) are statically fulfilled. Would need more work on tooling though.
Show threadgoedelchenMar 7
@bagder Stupid question:
What are non-c mistakes? Examples?
Show threaddaniel:// stenberg://Mar 7
@goedelchen see https://curl.se/docs/security.html
curl - CVEs

Show threadgmthorMar 8

@bagder

Why is there such a drop after 2017

Did you change something in the development process?
Since pace hasn’t slowed down since then?

Show threadNils Goroll 🕊️Mar 8

@bagder on the low res preview, i read AI vulnerabilities.

that's where the future growth is!

Show threadrk: it’s hyphen-minus actuallyMar 11

@bagder

God help me I thought this was a map of Virginia at first.

Show threadMaxMar 11

@bagder curious: is the year on this graph the year a vulnerability was introduced or was found?

UPD: oh, sorry, existing in code

Show threadTomMar 12

@bagder While the number of "C mistakes" is low, I would argue that, because of their nature, their impact can be worse. So, when writing code, they require more focus, which may lead to less focus to the rest of mistakes.

(In other words, when using a "memory safe" language, more focus may be dedicated on the logic)

Show threaddaniel:// stenberg://Mar 12
@tdelmas that's one dimension sure. But at the same time, C mistakes are typically easier to find with fuzzing, valgrind and sanitizers than the non-C mistakes...
Show threadTomMar 12

RE: https://mastodon.social/@bagder/116190180144118829

@bagder Some yes, but the ones that escape the first analysis seams to stay alive a very long time according to your answer.

(Just to clarify, this was not a suggestion to rewrite curl in another language)

https://mamot.fr/@[email protected]al/116190180281941410