> On 22 Jun 2023, at 23:50, Peter Firmstone <peter.firmst...@zeus.net.au> wrote: > > > If you are able to share, I'd be interested to learn about challenges you had > with SM, if we one day have the opportunity to reimplement it, the lessons > might be valuable, so we can avoid the same mistakes.
Much of the effort has to do with maintaining the doPrivileged calls in the right places, which needs to be done across the board, and testing all those locations with and without an installed SM. Let me just be clear that even though it’s the cost that made SM harmful and justified the effort involved in removing it, we believe that the stack-based approach is fundamentally flawed for an ecosystem where deep and wide dependency hierarchies are common and configurations must be tailored for a specific architecture and dependency set rather than in a black box fashion. We would advocate for simpler designs that have shown greater effectiveness. > > Serialization filters are lazily initialized, this is a performance > optimisation (a security trade off), however if a program doesn't utilise > serialization and has disabled serialization using a filter, this provides an > opportunity for an attacker. For the attack to be successful, the attacker > needs to change the serialization filter properties, prior to initialization, > if the attacker is successful, they will be able to disable the only security > mechanism protecting de-serialization against attack. I’m not sure that’s right. Briefly looking at the code, it seems that if you set jdk.serialFilter on the command line, you cannot set it again from the program (you can set the property, but it looks to me like the new value will be ignored). But I’m not familiar with the implementation at all and I could be wrong. In any event, that’s an unrelated topic. — Ron
