@brodriguesco I’m no expert but isn’t this kind of “if you install a package you’re already trusting it anyway”?.Seems like this could obscure stuff but still kind of expected no? … will be interesting to see how it gets rated
@_TimTaylor@brodriguesco The supply chain attack part is bogus, because a package can also have an .onLoad() function, or a library init hook in C, so package authors can still run code on your machine, when you load their package.
@gaborcsardi yeah that was pretty much my thinking. Not sure whether any distros will think it worthy of back porting though as seems a bit meh 🤷♂️ @brodriguesco
@klmr@brodriguesco I am not sure, but I heard from an R core member that they were getting more security notifications. It could be that they fixed those but not "disclose" them in the NEWS.
… unfortunately it’s still trivial to perform arbitrary code execution upon deserialisation even in R 4.4 😠
Now I need to find out how to disclose this. I’m not even sure responsible disclosure makes sense here since I’m sure others will either have found this already or will very soon find it.
@hrbrmstr@joranelias@Lluis_Revilla@brodriguesco@idavydov Right, it’s as much “expected behaviour” as in CVE-2024-27322, and as in other serialisation engines (e.g. Python pickle, .net BinaryFormatter, etc.). Which are all systems that are very hard to use correctly, and cause frequent direct vulnerabilities. Whether that makes the serialisation frameworks themselves a vulnerability… 🤷
(I did not register a CVE; for me this is an issue of awareness and documentation.)
@klmr@joranelias@brodriguesco This might fall into what others have complained about CVE: https://daniel.haxx.se/blog/2023/09/05/bogus-cve-follow-ups/
But here is the extract from Bug Reporting in R: "By default, reports submitted to R’s Bugzilla are public. If you believe your bug is a security vulnerability and should not be public, you may select “Show advanced fields” on the bug submission page, scroll down to the bottom of the page, and check that only members of R-security group are allowed to see the bug. "
@Lluis_Revilla Thanks, that’s what I was missing. I’ll see if I can find my old Bugzilla account info.
(As mentioned in another comment I disagree that deserialisation code execution bugs are “bogus CVEs” @bagder is rightly complaining about!]. In fact, they are amongst the most-exploited vulnerabilities.)
@klmr@Lluis_Revilla@bagder Known, designed-in, expected behavior is not a CVE.As @median_headroom noted in the reply, buffer overflows would be.
The real issue here is that 99% of R users are just trying to get stuff done and don't even realize the dangers.
I can shove code into . onAttach that exfiltrates your environment variables after remotes::install_github(x) & library(x) (nobody reads src before doing that). That doesn't get a CVE either.
@klmr@Lluis_Revilla@bagder@median_headroomsave.image (which I think I've used ~6x deliberately) came in super-handy those 6x and has the same underlying issues.
The manual pages need some DANGER WILL ROBINSON or HERE BE DRAGONS verbiage and it would be great if the [de]serialization did some checks and provided some unsilenceable warnings if risky objects are present.
@klmr@brodriguesco the deserialization code was changed so if there is a promise in the rds file an error is raised instead of leaving the promise there.
I always assumed reading an rds file downloaded from a random website was as safe as loading a package downloaded from a random website, apparently others thought rds files were much safer.
Add comment