[ANN] TypedJSON.jl - A Julia serialization library prioritizing type fidelity, human-readability, and long-term archival

[foobar_lv2]

@gcalderone

But it’s not clear to me how one can perform shell-popping here by just providing a malicious JSON file to deserialize. Can you provide an explicit example?

No, not with the gadgets you provide – as I said, I did not see an obvious way.

I can give you two analogies:

1. Security issue: Type confusion, convert called during deserialization · Issue #117 · JuliaIO/JLD2.jl · GitHub is an example how to pop a shell when deserializing jld2
2. In the java world, https://medium.com/@dub-flow/deserialization-what-the-heck-actually-is-a-gadget-chain-1ea35e32df69 explains the notion of deserialization gadgets.

In jld2, I used the following gadgets:

1. Broadcasted objects can execute shell-commands on index access Base.Broadcast.Broadcasted(run, ([`cat /etc/passwd`],))
2. convert accesses indices
3. jld2 sometimes calls constructors that call convert during deserialization

Your situation is better than jld2’s: You only deserialize things that have explicit reconstruct methods.

The bad thing is the fact that the set of gadgets is still a global thing: all methods of reconstruct for you – and this is expected to be extended by packages / people; and all classes implementing Serializable on the classpath in java. Hence, it is insufficient to say whether “one package (including its upstream / dependencies)” has usable gadgets. In this approach, security does not compose: The whole program / environment needs to be analyzed. In other words, using Foo and using Bar may both lead to safe environments, but using Foo, Bar may contain an exploitable gadget chain, due to interactions between Foo and Bar gadgets that are benign in isolation.

This makes security unmaintainable.

The annoying approach to fix that is that each deserialize call needs to already limit to a bounded world of reachable types that can be produced. Then, assuming no type piracy, each such call / world can be analyzed in isolation. In other words: You can safely deserialize Foo objects in one part of your program, and you can safely deserialize Bar objects in another part of your program; but you cannot safely deserialize mixed Foo/Bar objects, due to bad interactions; hence, the set of deserializable objects must be local to each part of your program, not global.

PS.

@gcalderone

As long as I understand you need both the JSON file and a malicious package to do the job, hence the problem becomes to warn the user not to install untrusted packages… Or am I missing something?

No. You need a malicious JSON file and a vulnerable combination of packages. Due to the global construction, it is insufficient for each package to be not-vulnerable in isolation.