Live data from Hacker News

Curl/libcurl HIGH CVE-2023-38545 leaked early?

gitlab.com

21–30 of 32 posts

Re: Curl/libcurl HIGH CVE-2023-38545 leaked early?

#21
post #10
post #9

Earlier quoted context omitted.

The patch was supposed to be published around 06:00 UTC on October 11. The commit is 13 hours early.

Perhaps, but to be honest trying to coordinate times on a specific disclosure day is futile. I would imagine Daniel is aware of this phenomenon.

> When there is a HIGH CVE security flaw, why then not release immediately after fix has been applied, but at a set date?

It's a valid question.

Re: Curl/libcurl HIGH CVE-2023-38545 leaked early?

#22
post #21
post #10

Earlier quoted context omitted.

Perhaps, but to be honest trying to coordinate times on a specific disclosure day is futile. I would imagine Daniel is aware of this phenomenon.

> When there is a HIGH CVE security flaw, why then not release immediately after fix has been applied, but at a set date? It's a valid question.

That has been answered several hundred times before, by Daniel himself in the original advisory.

Usually ubiquitous projects like this will privately distribute patches to large distros or corps so they can push security updates or at least prepare to push them on the disclosure date so that risk of exploit is lower by the date of disclosure. Otherwise there would be a lag and people would be more exposed for a period after disclosure.

Re: Curl/libcurl HIGH CVE-2023-38545 leaked early?

#23
post #12
post #6

cURL's own tracker had a banner stating severity High to be released October 11. It's October 11 and was already October 11 for a lot of the world 13 hours ago (as of writing) when this patch was posted. Nothing was early, nothing was leaked. EDIT: Why the downvotes? People don't like timezones or something?

> The new version and details about the two CVEs will be published around 06:00 UTC on the release day. https://github.com/curl/curl/discussions/12026 (2023-10-04T06:17:44Z)

That has to do with curl itself, redhat isn't necessarily bound to that schedule and we don't know the discussion that happened privately prior to disclosure date.

Re: Curl/libcurl HIGH CVE-2023-38545 leaked early?

#24
post #17

Will people stop messing with unsafe buffers in C already? Even just using C++ with the most basic buffer/dynamic array template would have prevented this issue.

While I agree with the general thrust of your comment, note that a) this is specifically adressed in Daniel's blog post b) He stated the reason why it's not happening right now multiple times already, and they seem well thought out. (Basically, the code base is huge and not easily converted, and there is no compiler support for some of the platforms libcurl supports). Engineering is based on trade offs. In this speci…

Yeah, it was more of a general "old man yells at cloud" comment not aimed at anything in particular. It's just frustrating that we shouldn't have 99% of these vulnerabilities. Don't even have to go all the way with the borrow checking and rust, just basic bounds checks on all containers through templates would be a massive improvement over using C. Yes, the performance will degrade by some single digit %, but nobody cares.

> and there is no compiler support for some of the platforms libcurl supports

I feel like there are no serious platforms that don't have at least a C++ compiler for it. Or am I wrong there?

Re: Curl/libcurl HIGH CVE-2023-38545 leaked early?

#25
post #23
post #12

Earlier quoted context omitted.

> The new version and details about the two CVEs will be published around 06:00 UTC on the release day. https://github.com/curl/curl/discussions/12026 (2023-10-04T06:17:44Z)

That has to do with curl itself , redhat isn't necessarily bound to that schedule and we don't know the discussion that happened privately prior to disclosure date.

That kind of approach leads to the party which broke ranks this time, not being included in confidential things in future.

Along the lines of "they've proven they can't be trusted", kind of thing.

Re: Curl/libcurl HIGH CVE-2023-38545 leaked early?

#26
post #23

Earlier quoted context omitted.

That has to do with curl itself , redhat isn't necessarily bound to that schedule and we don't know the discussion that happened privately prior to disclosure date.

That kind of approach leads to the party which broke ranks this time, not being included in confidential things in future. Along the lines of "they've proven they can't be trusted", kind of thing.

I don't agree they broke ranks. The 6am date was for the curl project itself.

Re: Curl/libcurl HIGH CVE-2023-38545 leaked early?

#27
post #26

Earlier quoted context omitted.

That kind of approach leads to the party which broke ranks this time, not being included in confidential things in future. Along the lines of "they've proven they can't be trusted", kind of thing.

I don't agree they broke ranks. The 6am date was for the curl project itself.

Probably depends on whether Red Hat was party to privileged info as part of a co-ordinated release for this. Personally, I have no idea.

Re: Curl/libcurl HIGH CVE-2023-38545 leaked early?

#28

Earlier quoted context omitted.

There are tons of shady open or semi-open proxies out there.

There's also PAC/WPAD ( https://en.wikipedia.org/wiki/Web_Proxy_Auto-Discovery_Proto... ). Together with some DHCP/ARP/DNS spoofing this might allow escalating from layer 2 connectivity (e.g. on a public wifi) to local root.

Seems like you'd need to set the Socks5 options manually to (lib?)curl which means parsing that PAC/WPAD file manually in your application and configuring curl based on its outcome? How many applications actually do this?

Re: Curl/libcurl HIGH CVE-2023-38545 leaked early?

#29
post #26

Earlier quoted context omitted.

I don't agree they broke ranks. The 6am date was for the curl project itself.

Probably depends on whether Red Hat was party to privileged info as part of a co-ordinated release for this. Personally, I have no idea.

I'd be surprised if not, but even then, it's not clear if the time was a requirement set by the cURL team at all for projects that aren't cURL.

Re: Curl/libcurl HIGH CVE-2023-38545 leaked early?

#30
post #23
post #12

Earlier quoted context omitted.

> The new version and details about the two CVEs will be published around 06:00 UTC on the release day. https://github.com/curl/curl/discussions/12026 (2023-10-04T06:17:44Z)

That has to do with curl itself , redhat isn't necessarily bound to that schedule and we don't know the discussion that happened privately prior to disclosure date.

RedHat is one of the subscribers of the mailing list where the CVE details were sent under embargo, so yes, they were bound to that and broke the embargo 13 hours earlier than the lift date.
Post reply on HN