Re:RegreSSHion: RCE in OpenSSH's server, on glibc-based Linu...
by michaelt on Monday July 01, 2024 @06:56PM
(#40851732)
> "only intended for processing data from trusted sources" is a frankly ridiculous policy for a serialization/deserialization library.
Truly, it's a design decision so ridiculous nobody else has made it. Except Python's pickle, Java's serialization, Ruby's Marshal and PHP's unserialize of course. But other than that, nobody!
Re:RegreSSHion: RCE in OpenSSH's server, on glibc-based Linu...
by YoumuChan on Tuesday July 02, 2024 @12:13AM
(#40853503)
And Lua's bytecode loader, recently discussed here: https://news.ycombinator.com/item?id=40830005
Re:RegreSSHion: RCE in OpenSSH's server, on glibc-based Linu...
by Dylan16807 on Tuesday July 02, 2024 @02:06AM
(#40853942)
I know "code is data", but it's a couple orders of magnitude more reasonable to have unsafe bytecode than to have unsafe data deserialization.
If something is supposed to load arbitrary code, not just data, that needs to be super clear at a glance. If it comes across as a data library, but allows takeover, you have a problem. Especially if there isn't a similar data-only function/library.
Yes, it is correct to file a CVE of the highest priority against your project, because "only intended for processing data from trusted sources" is a frankly ridiculous policy for a serialization/deserialization library.
If it's your toy project that you never expected anyone to use anyway, you don't care about CVEs. If you want to be taken seriously, you cannot play pass-the-blame and ignore the fact that your policy turns the entire project into a security footgun.