4 ms·
Java had a long list of this class of vulnerability, because it lets you build frameworks that lookup class by name. It's no longer common to do that in Java,
by danielheath 4y ago
Java had a long list of this class of vulnerability, because it lets you build frameworks that lookup class by name.
It's no longer common to do that in Java, because after the CVEs were reported, framework authors changed the API. This process also happened in ruby. Not familiar enough with other ecosystems to be sure but I'd bet money it's hit a fair few of them.
- lolinder 4y agoI'd file that under "weird stuff you can do with the deserialized object", and static types certainly don't protect you from that (edit: or from dangerous serializer libraries). This bug isn't in that category, though: this happened because GitLab assumed they had a specific data type but didn't guarantee that this was always true. The build_command method, in turn, does something different depending on the type of data passed into it. This line in the Ruby code: id = id_for_already_imported_cache(object) Would translate to this in the Java code: Object id = idForAlreadyImportedCache(object) Which would immediately set off alarm bells in the mind of the author that they should probably double-check they've got the right type.
- paranoidrobot 4y agoThere's a similar set of problems with .NET and BinaryFormatter and a few other things. MS now have a security guide on using them: https://learn.microsoft.com/en-us/dotnet/standard/serialization/binaryformatter-security-guide https://learn.microsoft.com/en-us/dotnet/standard/serializat...