[olliej]

Looks like another "I'm in a 'safe' language, so can do unsafe things" crossed with the standard object deserialization error of default allowing any class to be instantiated.

The temporary fix that they list seems to imply that the current APIs don't allow specifying a finite list of allowed classes?

[dboreham]

Any kind of writable reflection facility, and any kind of eval() should be added to the set of "unsafe" features.

[hsbauauvhabzb]

At some point, mvc frameworks have to do some magic to dynamically load classes. This should be done at runtime, but can’t imagine it’s an easy problem to solve.

[richbell]

Frameworks like Quarkus and Micronaut do this at compile time. They dynamically load things and record it, then insert the resulting bytecode statically in the build artifact. I believe the core motivator is performance, but it has the added benefit of eliminating most of the runtime magic that leads to vulnerabilities like this.

[olliej]

No they don’t, MVC has existed in C++ for decades. The problem is specific to reflection based MVC frameworks (objc has similar issues).

The solution is to explicitly specify every class that can be instantiated at compile time. Similar to how modern deserialization frameworks work. No code should be written that allows content from the network to explicitly specify arbitrary code to load and execute. E.g having a packet say <view class=“MyView”> and feeding the string “MyView” into some classloader, or dlsym, or whatever is asking for trouble. Feeding it into

    switch (view.class) {
       case “MyView”: return new MyView() … }

Results in a much less powerful primitive

[dboreham]

Not my field, but how can this be so? We had MVC in 1990 written in C or C++.

[olliej]

In principle I think you could do something like this with COM, but I’m unaware of any such framework