daniel:// stenberg://

6 months ago

daniel:// stenberg://
6 months ago

C mistakes among the vulnerabilities present in #curl code

(C mistakes are vulnerabilities that were caused by a mistake that "probably would not have been possible" had we not been using C for curl. Manually assessed for each case.)

#curl

in reply to daniel:// stenberg://

Wolf480pl

in reply to daniel:// stenberg:// 6 months ago

does the date refer to when the bug was introduced, or when it was discovered/fixed?

in reply to Wolf480pl

daniel:// stenberg://

in reply to Wolf480pl 6 months ago

@wolf480pl it shows them when they were present in releases, thus from we introduced them until we fixed them

@Wolf480pl

in reply to daniel:// stenberg://

Wolf480pl

in reply to daniel:// stenberg:// 6 months ago

would be interesting to see it as two lines: vulnerabilities added before date, and vulnerabilities fixed before date. That way it'd be possible to tell the difference between "fewer vulns in these years because there wasn't time to find them yet" vs "fewer vulns in these years because we're doing something better"

in reply to Wolf480pl

daniel:// stenberg://

in reply to Wolf480pl 6 months ago

@wolf480pl we can't possibly tell that. I mean, for all we know there are also N additional flaws not yet reported that could completely change the look of that graph a few years in the future. We can never know if we actually improved or if the flaws just haven't been reported yet. Well, until perhaps after 10-12 years or so.

@Wolf480pl

in reply to daniel:// stenberg://

daniel:// stenberg://

in reply to daniel:// stenberg:// 6 months ago

@wolf480pl we have this graph also to show intro/fixed

@Wolf480pl

in reply to daniel:// stenberg://

Wolf480pl

in reply to daniel:// stenberg:// 6 months ago

what I mean is this

in reply to Wolf480pl

Wolf480pl

in reply to Wolf480pl 6 months ago

of course we can't know that the yellow line on the graph isn't lower than it is in reality.

But what I expected to see would be the yellow line flattening out in the last few years, due to new vulns not having the time to be found.

It didn't, which seems to suggest vulns are found pretty quickly.

Though I'm not a data analyst, my conclusions could be completely off...

This entry was edited (6 months ago)

in reply to Wolf480pl

daniel:// stenberg://

in reply to Wolf480pl 6 months ago

@wolf480pl It looks like this, an existing graph:

@Wolf480pl

in reply to daniel:// stenberg://

Wolf480pl

in reply to daniel:// stenberg:// 6 months ago

if only I had searched 😅

in reply to daniel:// stenberg://

locnide

in reply to daniel:// stenberg:// 6 months ago

Is there an hypothetical explanation of the reduction of C mistakes share between 2017 and 2020 ? Was the C tooling able to catch more mistakes?

This entry was edited (6 months ago)

in reply to locnide

daniel:// stenberg://

in reply to locnide 6 months ago

@koalp better tools, more tests and us writing code better code (avoiding certain patterns, using helper functions etc) I think. But the decline is also relatively new, maybe we just haven't found those flaws yet...

@locnide

in reply to daniel:// stenberg://

Julien W.

in reply to daniel:// stenberg:// 6 months ago

do you know how much time in average a flaw was present in releases?

@koalp

@locnide

in reply to Julien W.

daniel:// stenberg://

in reply to Julien W. 6 months ago

@julienw @koalp yes: median time ~6 years, average ~8 years

@locnide @Julien W.

in reply to daniel:// stenberg://

varx/tech

in reply to daniel:// stenberg:// 6 months ago

@koalp Yeah, I strongly suspect that part of the graph will "fill in" with time.

It would be interesting to look at how this graph would have looked in, say, 2015 -- similar curve, or different?

@locnide

in reply to varx/tech

daniel:// stenberg://

in reply to varx/tech 6 months ago

@varx @koalp quite This are renders of the same graph done as if it was 2015-01-01 and 2020-01-01.

The 2020 one is interestingly different and shows a much higher C mistake degree than today.

@varx/tech @locnide

in reply to daniel:// stenberg://

🪨

in reply to daniel:// stenberg:// 6 months ago

This 2017 cutoff still looks very similar, was there a specific event or policy change maybe that could explain it?

in reply to 🪨

daniel:// stenberg://

in reply to 🪨 6 months ago

@Varpie @varx @koalp I can't recall any, and I did scan the changelogs for 2017 releases but it did not bring any such thing back. We started fuzzing in 2018.

@varx/tech @locnide @🪨

in reply to daniel:// stenberg://

papush

in reply to daniel:// stenberg:// 6 months ago

what helped bring them down most?

in reply to papush

daniel:// stenberg://

in reply to papush 6 months ago

@papush there is no such specific correlation. We do things in the repo to improve things but vulnerabilities are often reported MUCH later so it is hard to tell what has effect, how much and when we can be sure...

@papush

in reply to daniel:// stenberg://

Oliver Schönrock

in reply to daniel:// stenberg:// 6 months ago

Interesting, what happened between 2016 and 2020?

in reply to Oliver Schönrock

daniel:// stenberg://

in reply to Oliver Schönrock 6 months ago

@oschonrock we developed curl!

@Oliver Schönrock

in reply to daniel:// stenberg://

Oliver Schönrock

in reply to daniel:// stenberg:// 6 months ago

Sure.

Seems the vulnerabilities plummeted, and specifically C-vulnerabilities collapses to almost nothing during that period.

Did you rewrite/retire tons of old code?

Or change your toolset/processes?

in reply to Oliver Schönrock

daniel:// stenberg://

in reply to Oliver Schönrock 6 months ago

who knows. The graph is based on what we know *now* not what we knew back then. We always polish, improve and add tests. There was nothing magic done in that period. Just iterative improvements.

This entry was edited (6 months ago)

in reply to daniel:// stenberg://

Martin Uecker

in reply to daniel:// stenberg:// 6 months ago

For the C mistakes, what kind of mistakes were those?

in reply to Martin Uecker

daniel:// stenberg://

in reply to Martin Uecker 6 months ago

@uecker curl.se/docs/security.html#c%2…

curl - CVEs

^curl.se

@Martin Uecker

in reply to daniel:// stenberg://

Martin Uecker

in reply to daniel:// stenberg:// 6 months ago

Cool! Thanks!

in reply to Martin Uecker

Martin Uecker

in reply to Martin Uecker 6 months ago

I see that cull has a buffer abstract (dynbuf) which I assume is safe. Why does this not eliminate oob errors? Limitations of its API which make it unsuitable in some situations? Other reasons? Or just old code which was written before this abstraction was introduced?

in reply to Martin Uecker

daniel:// stenberg://

in reply to Martin Uecker 6 months ago

@uecker primarily because far from everything can use dynbufs

@Martin Uecker

in reply to daniel:// stenberg://

Martin Uecker

in reply to daniel:// stenberg:// 6 months ago

This is something I would like to try to understand a little bit better. I started to use safe buffer / string abstractions in new code and I did not encounter any obstacle so far (except, of course, more work to build those types)

in reply to Martin Uecker

daniel:// stenberg://

in reply to Martin Uecker 6 months ago

@uecker I'm thinking cases like curl.se/docs/CVE-2024-6874.htm… etc

curl - macidn punycode buffer overread - CVE-2024-6874

^curl.se

@Martin Uecker

in reply to daniel:// stenberg://

Martin Uecker

in reply to daniel:// stenberg:// 6 months ago

This seems a flaw of an external library, but also something a string abstraction should catch when converting the buffer...

in reply to Martin Uecker

daniel:// stenberg://

in reply to Martin Uecker 6 months ago

@uecker exactly. Something we cannot use dynbufs for, which also caused us a problem...

@Martin Uecker

in reply to daniel:// stenberg://

Martin Uecker

in reply to daniel:// stenberg:// 6 months ago

Sorry, if I am annoying, I just want to understand this better. I do not understand why so much C code does hand-rolled buffer and string management with open-coded pointer arithmetic, when this can all be abstracted away behind safe interfaces. What am I missing? Interfacing to external libraries certainly then needs conversion which could still cause issues, but this is true also for memory safe languages.

in reply to Martin Uecker

daniel:// stenberg://

in reply to Martin Uecker 6 months ago

@uecker a) there is no standard "safe interface" for strings in C, it's all handrolled or a 3rd party library. b) we all do our best with limited time and energy and it is an ongoing life that keeps changing. c) feel free to help out

@Martin Uecker

in reply to daniel:// stenberg://

Martin Uecker

in reply to daniel:// stenberg:// 6 months ago

I am trying to help on the "no standard" point (and also compilers), this is why I am curious. Maybe social media is not ideal to discuss this, I assume there are many practical issues. But you experience would be extremely valuable. Maybe you have some time for some discussion at some point?

in reply to daniel:// stenberg://

Paul Hoffman

in reply to daniel:// stenberg:// 6 months ago

Please say more or link to the description of the other mistakes!

in reply to Paul Hoffman

daniel:// stenberg://

in reply to Paul Hoffman 6 months ago

@paulehoffman all the 167 mistakes (that led to the vulnerabilities) are documented here: curl.se/docs/security.html

curl - CVEs

^curl.se

@Paul Hoffman

in reply to daniel:// stenberg://

tmaher

in reply to daniel:// stenberg:// 6 months ago

thank you so much for the C bug labeling and short taxonomy. There’s so much hand-waving discussion around memory management security — it’s nice to see real statistics from a significant project like cURL.

in reply to daniel:// stenberg://

Alavi | علوی

in reply to daniel:// stenberg:// 6 months ago

rerwrite curl in rust confirmed? XD

Unknown parent

daniel:// stenberg://

Unknown parent 6 months ago

@isotopp I wish it was that simple

@Kris

Unknown parent

daniel:// stenberg://

Unknown parent 6 months ago

@jens @isotopp C++ would not really have improved anything as all the C mistakes can be done with C++ as well. After my years with Firefox C++ I am scarred and can only think of all the harm C++ can do. Handing over firearms to toddlers kind of harm.

@Jens Finkhäuser @Kris

⇧

daniel:// stenberg:// 6 months ago • •

daniel:// stenberg://
6 months ago