Critical flaw in Protobuf library enables JavaScript code execution(bleepingcomputer.com)
bleepingcomputer.com
Critical flaw in Protobuf library enables JavaScript code execution
https://www.bleepingcomputer.com/news/security/critical-flaw-in-protobuf-library-enables-javascript-code-execution/
11 comments
Lots more details from Endor labs (flaw finder & source): https://www.endorlabs.com/learn/the-dangers-of-reusing-proto...
> the library builds JavaScript functions from protobuf schemas by concatenating strings and executing them via the Function() constructor, but it fails to validate schema-derived identifiers, such as message names.
Typical "eval is evil" issue.
Typical "eval is evil" issue.
How does the attacker supply a malicious schema? Can that be turned off? It doesn't seem like a normal thing to do.
I think something like this: Imagine a tool for querying remote grpc endpoints - you would point at some endpoint to query it / explore it, and the tool would request the proto schema files from a potentially untrusted source - something you would not expect to be that unsafe and trigger an rce.
probably via normal npm injection server side.
But once you can make people download your malicious js code using npm, why would you then need to inject malicious js code in protobuf?
Well, in this attack, you're using the vulenerable dev to modify their code to run a protobuf schema that's vulnerable; so then it can inject that vulnerability to the client code, and then you're exfilitrating 10's of users (the dev who ran this code isnt very popular).
Both "Javascript" and "Typescript" are incredibly flawed languages and the entire npm ecosystem is the bane of the software security industry.
I mean, I'm down to rip on JS/NPM any day of the week, but this specific issue isn't related to any JS/NPM-isms: it's a deserialization library which marshals language-specific objects from bytes using a variant of eval().
Any platform with eval (most implementations of Python, Perl, Lisp, Scheme, PHP, Ruby, Erlang, old editions/specific libraries of Java, Haskell, and many others) seems at risk for this type of issue.
Indeed, ser/de systems in those languages--all of them--have a long history of severe CVEs similar to this one.
It's also worth noting that this vuln has to do with the library's handling of .proto schema files, not data. The unsafe eval happens when a Protobuf schema file which itself describes the format of wire/data types is uploaded, not when the wire/data types themselves are deserialized. The majority of uses of Protobuf out there (in any language) handle the schema files rarely or as trusted input.
That doesn't make it safe/mitigated by any means, but it's worth being specific.
Any platform with eval (most implementations of Python, Perl, Lisp, Scheme, PHP, Ruby, Erlang, old editions/specific libraries of Java, Haskell, and many others) seems at risk for this type of issue.
Indeed, ser/de systems in those languages--all of them--have a long history of severe CVEs similar to this one.
It's also worth noting that this vuln has to do with the library's handling of .proto schema files, not data. The unsafe eval happens when a Protobuf schema file which itself describes the format of wire/data types is uploaded, not when the wire/data types themselves are deserialized. The majority of uses of Protobuf out there (in any language) handle the schema files rarely or as trusted input.
That doesn't make it safe/mitigated by any means, but it's worth being specific.
This is why I use Go.
I've built so much stuff in this. Code i wrote a decade back still builds and runs just fine.
It's still serving in Ad tech company, response time sub 5ms, p95
I've built so much stuff in this. Code i wrote a decade back still builds and runs just fine.
It's still serving in Ad tech company, response time sub 5ms, p95
Given that JS/TS is still near mandatory in the client and optional in server side, I doubt a high percent of the "50 million downloads" are server side. Are you using go in WASM and how's that working out?