Due to a recent report of potential vulnerability (along lines of
http://www.darkreading.com/informationweek-home/why-the-java-deserialization-bug-is-a-big-deal/d/d-id/1323237
-- although not exactly that one) I have worked a bit on figuring out
how to block deserialization of known problem classes in context of
polymorphic type handling -- and especially for "default typing" which
can enable such handling for all kinds of payloads.
After adding about half a dozen cases I realized one thing: although
it may make sense to add a small list of definite known bad cases,
more generally there should be a way to:
1. Allow users to provide their own definitions of types to avoid (and
action taken, from throwing exception to masking "bad values" as
`null`s)
2. Allow rapid release of new versions of protective settings to be
deployed without forcing full release of Jackson tool suite
3. Support older Jackson versions, and not just 2 or 3 most recent
minor versions.
and that trying to provide this directly via `jackson-databind` is not
the best way to go: although (1) could be done by providing
configurability, (2) would always limit the response due to big
overhead of full releases (and "version pollution"). And (3) is
similarly limited by cost of support.
Further, since the actual logic can be nicely plugged in via Module
API already -- after all, all that is needed is for a module to
register itself as deserializer and/or serializer provider! -- it's
trivially easy to add such protection via module. Moreover, it is
possible to keep module more backwards compatible to work with a
wide(r) range of Jackson versions.
Now. I think this is the way to go, and I want to get started soon.
But there are couple of things that warrant discussion. Here are some
things that come to my mind:
- Naming: I guess this could be considered a datatype module? Or just
regular one? But it'd be nice to have catchy name (similar to ones
that I like, "mr bean" and "Afterburner")... suggestions? :)
- Versioning: unlike all existing modules, this one should NOT -- in
my opinion -- be co-versioned with other components, because:
(a) There may need to rapidly produce new versions, outside
regular release cycle
(b) To maximize usefulness, version should NOT have to match with
other components -- or put another way, multiple "core" minor versions
should be able to use same "security module"
- .... but if so, how should we version this? I suggest that
Major version should match -- but maybe this should use date?
2017.4.17?
- Here we assume that it is possible to make truly 2.x
compatible module: I believe this is actually true, meaning that
module would work with all core versions from 2.0.0 to 2.9.0.pr2 and
beyond
- Maintenance, dev team: I am not a Java security/vuln expert by any
means. Ideally I think team would consist of and even be lead by
others with more expertise in this area.
- Release cycle: sort of released to 2 previous points, should figure
out both development and release workflow.
Apologies for bit disorganized description; I just want to get this
module started soon now, since I feel there is some urgency to
releasing first version(s) of this module.
But also "get it right" wrt versioning, releases, other policy aspects.
-+ Tatu +-
ps. If anyone feels there might be some commercial interest in this
area of support, this might also be useful (although if so, maybe drop
a note to `info` at fasterxml dot com)
--
You received this message because you are subscribed to the Google Groups
"jackson-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
