mastodon - Link to source

daniel:// stenberg://

2 weeks ago

daniel:// stenberg://
2 weeks ago

Joshua Rogers sent us a *massive* list of potential issues in #curl that he found using his set of AI assisted tools. Code analyzer style nits all over. Mostly smaller bugs, but still bugs and there could be one or two actual security flaws in there. Actually truly awesome findings.

I have already landed 22(!) bugfixes thanks to this, and I have over twice that amount of issues left to go through. Wade through perhaps.

Credited "Reported in Joshua's sarif data" if you want to look for yourself

#curl

in reply to daniel:// stenberg://

mastodon - Link to source

Wolf480pl

in reply to daniel:// stenberg:// 2 weeks ago

so this is what an AI can do when wielded by a competent human?

in reply to Wolf480pl

mastodon - Link to source

daniel:// stenberg://

in reply to Wolf480pl 2 weeks ago

@wolf480pl yes! and this after three competent code analyzers already say "no issues found" ...

@Wolf480pl

in reply to daniel:// stenberg://

mastodon - Link to source

Brodie Robertson

in reply to daniel:// stenberg:// 2 weeks ago

This is kind of happening in a lot of industries and should be expected, competent people will always be able to make the most of the tools they have available, but people who aren't will try to cut corners with new tools

This entry was edited (2 weeks ago)

in reply to Brodie Robertson

mastodon - Link to source

daniel:// stenberg://

in reply to Brodie Robertson 2 weeks ago

@BrodieOnLinux indeed. In this case I'm almost blown away by the quality of some of this...

@Brodie Robertson

in reply to daniel:// stenberg://

mastodon - Link to source

daniel:// stenberg://

in reply to daniel:// stenberg:// 2 weeks ago

Here's a simple example where it reports that we considered a nread == 0 as reading a byte, when we shouldn't.

First-byte timestamp is set on zero-length (EOF) socket read in lib/cf-socket.c In lib/cf-socket.c the code calls sread(ctx->sock, buf, len) atline 1549 and, on the non-error path, unconditionally sets *pnread = (size_t)nread atline 1578. If nread == 0 (EOF / zero-length read) the function
leaves result as CURLE_OK and the subsequent check at lines 1581-1584 (if (!result && !ctx->got_first_byte)) sets ctx->first_byte at = curlx_now() and ctx->got_first_byte = TRUE. This causes the connection to be marked as having received its “first byte” even though no bytes were actually read, corrupting time-to-first-byte metrics and any higher-level logic that relies on ctx->got_first_byte.

This entry was edited (2 weeks ago)

in reply to daniel:// stenberg://

mastodon - Link to source

Christopher Snowhill

in reply to daniel:// stenberg:// 2 weeks ago

Am I reading this right, this looks like it describes an sread function call, then displays a code snippet of the exact line and there's no sread call.

in reply to Christopher Snowhill

mastodon - Link to source

daniel:// stenberg://

in reply to Christopher Snowhill 2 weeks ago

@chris the code snippet is off, but the description is 100% accurate

@Christopher Snowhill

in reply to daniel:// stenberg://

mastodon - Link to source

Christopher Snowhill

in reply to daniel:// stenberg:// 2 weeks ago

Oh, wow. Then I guess I misjudged this. So glad someone managed to make an LLM pay off and provide good code analysis.

in reply to Christopher Snowhill

mastodon - Link to source

daniel:// stenberg://

in reply to Christopher Snowhill 2 weeks ago

@chris look at this one, where the tool "knows" lots of details of the protocol neg details and can report this masterpiece on the curl telnet code:

Telnet subnegotiation writes unescaped user-controlled values (tn->subopt_ttype, tn->subopt_xdisploc, tn-
>telnet_vars) into temp (lines 948-989) without escaping IAC (OxFF)
In lib/telnet.c (lines 948-989) the code formats Telnet subnegotiation payloads into temp using msnprintf and
inserts the user-controllable values tn->subopt_ttype (lines 948-951), tn->subopt_xdisploc (lines 960-963), and v-
>data from tn->telnet_vars (lines 976-989) directly into the suboption data. The buffer temp is then written to the
socket with swrite (lines 951, 963, 995) without duplicating CURL_IAC (OxFF) bytes. Telnet requires any IAC byte inside
subnegotiation data to be escaped by doubling; because these values are not escaped, an OxFF byte in any of them will
be interpreted as an IAC command and can break the subnegotiation stream and cause protocol errors or malfunction.

@Christopher Snowhill

in reply to daniel:// stenberg://

mastodon - Link to source

Christopher Snowhill

in reply to daniel:// stenberg:// 2 weeks ago

Yikes! What a find.

in reply to daniel:// stenberg://

mastodon - Link to source

penguin42

in reply to daniel:// stenberg:// 2 weeks ago

@chris Oh wow - I've not seen AI get the underlying structure/protocol before.

@Christopher Snowhill

in reply to daniel:// stenberg://

mastodon - Link to source

Ondřej Kolín

in reply to daniel:// stenberg:// 2 weeks ago

in the alt text the nread equals copyright 😅

in reply to Ondřej Kolín

mastodon - Link to source

daniel:// stenberg://

in reply to Ondřej Kolín 2 weeks ago

@ondrejkolin yeah sorry, I did not proof read the alt text properly

@Ondřej Kolín

in reply to daniel:// stenberg://

mastodon - Link to source

Stefan Eissing

in reply to daniel:// stenberg:// 2 weeks ago

well, if the socket read returns ok and 0 length, we received the first reply from the server, eg that it closed the connection on its end.

That is what the senantics of „first_byte“ is supposed to track. The var would have been better named „first_reply“.

tldr

The code was correct, the naming was wrong.🤷🏻‍♂️

in reply to Stefan Eissing

mastodon - Link to source

daniel:// stenberg://

in reply to Stefan Eissing 2 weeks ago

@icing oh...

@Stefan Eissing

in reply to daniel:// stenberg://

mastodon - Link to source

Jeroen Massar

in reply to daniel:// stenberg:// 4 days ago

@icing aha, so... is this still AI^WLLM slop or is it "something a human should still sort out, but useful pointers to possible issues"?

@Stefan Eissing

in reply to daniel:// stenberg://

mastodon - Link to source

MrMagne

in reply to daniel:// stenberg:// 2 weeks ago

Nice, what tools was he using ?

in reply to MrMagne

mastodon - Link to source

daniel:// stenberg://

in reply to MrMagne 2 weeks ago

@MrMagne this is his (long) blog post on his work: joshua.hu/llm-engineer-review-…

Hacking with AI SASTs: An overview of ‘AI Security Engineers’ / ‘LLM Security Scanners’ for Penetration Testers and Security Teams

Note: This post is complemented by a presentation I gave at KazHackStan 2025. The slides for that talk can be found here, or in pptx format here..

^{Joshua Rogers (Joshua.Hu Joshua Rogers’ Scribbles)}

@MrMagne

in reply to daniel:// stenberg://

mastodon - Link to source

God is one

in reply to daniel:// stenberg:// 2 weeks ago

sun is not doing Allah is doing to accept Islam say that i bear witness that there is no deity worthy of worship except Allah and Muhammad peace be upon him is his slave and messenger

in reply to daniel:// stenberg://

mastodon - Link to source

Ethan Black

in reply to daniel:// stenberg:// 1 week ago

Your run-in with AI + curl reports was on the YouTube channel Low Level, did you see it? youtu.be/-uxF4KNdTjQ
Sorry you have to deal with all that, that has to be frustrating... glad you're encountering good use of AI too

literally the dumbest thing I've ever read

Please stop.https://hackerone.com/reports/3340109🏫 MY COURSESSign-up for my FREE 3-Day C Course: https://lowlevel.academy🧙‍♂️ HACK YOUR CAREERWanna learn t...

^YouTube

in reply to daniel:// stenberg://

mastodon - Link to source

glyn

in reply to daniel:// stenberg:// 1 week ago

I wonder how many issues the AI tooling will find *after* those bugfixes are applied. Hopefully fewer!

in reply to daniel:// stenberg://

mastodon - Link to source

gnirre

in reply to daniel:// stenberg:// 1 week ago

Is Joshua Rogers a regular or a new contributor to cURL. Are these findings landing a lot of money in his pocket?

in reply to gnirre

mastodon - Link to source

daniel:// stenberg://

in reply to gnirre 1 week ago

@gnirre he's a new contributor, yes. So far none of his many reports have turned out to be a security vulnerability so we have not paid any money for them. We have merged lots of fixes though.

@gnirre

in reply to daniel:// stenberg://

mastodon - Link to source

daniel:// stenberg://

in reply to daniel:// stenberg:// 3 days ago

We have now landed more than 70 bugfixes based on Joshua's work.

in reply to daniel:// stenberg://

mastodon - Link to source

Jan Johannesson

in reply to daniel:// stenberg:// 3 days ago

😃 👍

in reply to daniel:// stenberg://

mastodon - Link to source

Bjørn Göttler

in reply to daniel:// stenberg:// 3 days ago

yay Joshua!!!

in reply to daniel:// stenberg://

mastodon - Link to source

daniel:// stenberg://

in reply to daniel:// stenberg:// 15 hours ago

now at more than 100 bugs fixed and we're not done yet...

in reply to daniel:// stenberg://

mastodon - Link to source

gasrios

in reply to daniel:// stenberg:// 14 hours ago (Received 13 hours ago)

did this affect or forced you to adapt curl's release cycle in any way?

I'm a huge fan, BTW, I think you are one of the best examples of leadership in the open source community.

in reply to gasrios

mastodon - Link to source

daniel:// stenberg://

in reply to gasrios 13 hours ago

@gasrios we normally do several hundred bugfixes per release cycle, so while this is more than normal it is not exceptional. Our release cycle is well established and I see no reason to alter it just because of this, no.

@gasrios

⇧