4 ms·

While I think garbage collected languages produce programs that are more safe, I also think they are often enablers for new classes of security issues. For exam

While I think garbage collected languages produce programs that are more safe, I also think they are often enablers for new classes of security issues. For example ysoserial, log4j etc.

tester756 5y ago
(This is genuine question) Is log4j's bug actually unique to Java/C#/gc-based languages?
- 41b696ef1113 5y ago
  >Is log4j's bug actually unique to Java/C#/gc-based languages? Not to my understanding. It would be possible in any language with or without a GC.
- catdog 5y ago
  No, not validating user input and passing it to some crazy feature rich library like JNDI is possible in any language. Not denying that Java did contribute by shipping with such an overengineered mess like JNDI in the first place. Log4Shell wasn't a bug, log4j worked as expected and documented. It's just a stupid idea for a logging library to work in such a way.
- jerf 5y ago
  The underlying bug in log4j is having a deserialization mechanism that can automatically deserialize to any class in the system, combined with method code that runs upon deserialization that does dangerous things. It has nothing to do with GC at all. It's a recurring problem in dynamic scripting languages where the language by its very nature tends to support this sort of functionality. It's actually a bit weird that Java has it because statically-typed languages like that don't generally have the ability to do that, but Java put a lot of work into building this into its language. Ruby has a very large issue with this a few years back where YAML submitted to an Ruby on Rails site would be automatically deserialized and execute a payload before it got to the logic that would reject it if nothing was looking for it. Python's pickle class has been documented as being capable of this for a long time, so the community is constantly on the lookout for things that use pickle that shouldn't, and so far they've mostly succeeded, but in principle the same thing could happen with that, too. It would be nearly impossible for Go (a GC'd language) to have that class of catastrophic security error, because there is nowhere the runtime can go to get a list of "all classes" for any reason, including deserialization purposes. You have to have some sort of registry of classes. It's possibly to register something that can do something stupid upon unmarshaling, but you have to work a lot harder at it. Go is not unique. You don't see the serialization bugs of this type in C or C++ either (non-GC'd languages), because there's no top-level registry of "all classes/function/whatever" in the system to access at all. You might get lots of memory safety issues, but not issues from deserializing classes that shouldn't be deserialized simply because an attacker named them. Many other languages make this effectively impossible because most languages don't have that top-level registry built in. That's the key thing that makes this bug likely.
  - formerly_proven 5y ago
    > The underlying bug in log4j is having a deserialization mechanism that can automatically deserialize to any class in the system Getting objects out of a directory services is what JNDI is all about, I'm hesitant to call it a bug. The bug is that Java is way too keen on dynamically loading code at runtime. Probably because it was created in the 90s, where doing that was kinda all the rage. I think retrospectively the conclusion is that it may be the easiest way to make things extensible short-term, but also the worst way for long-term maintenance. Just ask Microsoft about that.
    - jerf 5y ago
      "Getting objects out of a directory services is what JNDI is all about, I'm hesitant to call it a bug." I didn't call it a bug. I called it a bit of functionality that makes the security problem possible. There are many things that result in security issues that come from some programmer making something just too darned convenient, but are otherwise "features", not some mistake or something. It's the underlying problem. You should have to declare what classes are able to be deserialized. To the extent that it's inconvenient, well, so was the log4j issue.
- chromanoid 5y ago
  No, it's not unique. But a GC strengthens, like dynamic typing, your ability to develop more dynamically and together with reflection or duck typing to write code that can deal with to some extent unknown input more easily. You can pass arbitrary objects (also graphs of objects) around very generously. Ysoserial is based more or less on this idea. Passing arbitrary objects around was deemed so useful, that it is also supported by java's serialization mechanism and thus could be exploited. Log4shell exploits similar mechanisms that would be a hell to implement in non-gc languages.

While I think garbage collected languages produce programs that are more safe, I also think they are often enablers for new classes of security issues. For example ysoserial, log4j etc.

tester756 5y ago

(This is genuine question) Is log4j's bug actually unique to Java/C#/gc-based languages?

41b696ef1113 5y ago
>Is log4j's bug actually unique to Java/C#/gc-based languages? Not to my understanding. It would be possible in any language with or without a GC.
catdog 5y ago
No, not validating user input and passing it to some crazy feature rich library like JNDI is possible in any language. Not denying that Java did contribute by shipping with such an overengineered mess like JNDI in the first place. Log4Shell wasn't a bug, log4j worked as expected and documented. It's just a stupid idea for a logging library to work in such a way.
jerf 5y ago
The underlying bug in log4j is having a deserialization mechanism that can automatically deserialize to any class in the system, combined with method code that runs upon deserialization that does dangerous things. It has nothing to do with GC at all. It's a recurring problem in dynamic scripting languages where the language by its very nature tends to support this sort of functionality. It's actually a bit weird that Java has it because statically-typed languages like that don't generally have the ability to do that, but Java put a lot of work into building this into its language. Ruby has a very large issue with this a few years back where YAML submitted to an Ruby on Rails site would be automatically deserialized and execute a payload before it got to the logic that would reject it if nothing was looking for it. Python's pickle class has been documented as being capable of this for a long time, so the community is constantly on the lookout for things that use pickle that shouldn't, and so far they've mostly succeeded, but in principle the same thing could happen with that, too. It would be nearly impossible for Go (a GC'd language) to have that class of catastrophic security error, because there is nowhere the runtime can go to get a list of "all classes" for any reason, including deserialization purposes. You have to have some sort of registry of classes. It's possibly to register something that can do something stupid upon unmarshaling, but you have to work a lot harder at it. Go is not unique. You don't see the serialization bugs of this type in C or C++ either (non-GC'd languages), because there's no top-level registry of "all classes/function/whatever" in the system to access at all. You might get lots of memory safety issues, but not issues from deserializing classes that shouldn't be deserialized simply because an attacker named them. Many other languages make this effectively impossible because most languages don't have that top-level registry built in. That's the key thing that makes this bug likely.
- formerly_proven 5y ago
  > The underlying bug in log4j is having a deserialization mechanism that can automatically deserialize to any class in the system Getting objects out of a directory services is what JNDI is all about, I'm hesitant to call it a bug. The bug is that Java is way too keen on dynamically loading code at runtime. Probably because it was created in the 90s, where doing that was kinda all the rage. I think retrospectively the conclusion is that it may be the easiest way to make things extensible short-term, but also the worst way for long-term maintenance. Just ask Microsoft about that.
  - jerf 5y ago
    "Getting objects out of a directory services is what JNDI is all about, I'm hesitant to call it a bug." I didn't call it a bug. I called it a bit of functionality that makes the security problem possible. There are many things that result in security issues that come from some programmer making something just too darned convenient, but are otherwise "features", not some mistake or something. It's the underlying problem. You should have to declare what classes are able to be deserialized. To the extent that it's inconvenient, well, so was the log4j issue.
chromanoid 5y ago
No, it's not unique. But a GC strengthens, like dynamic typing, your ability to develop more dynamically and together with reflection or duck typing to write code that can deal with to some extent unknown input more easily. You can pass arbitrary objects (also graphs of objects) around very generously. Ysoserial is based more or less on this idea. Passing arbitrary objects around was deemed so useful, that it is also supported by java's serialization mechanism and thus could be exploited. Log4shell exploits similar mechanisms that would be a hell to implement in non-gc languages.