17 ms·

These Log4j issues aren't real hardcore exploits. They wrote a logger that could run arbitrary code, then were surprised when attackers figured out how to run

These Log4j issues aren't real hardcore exploits. They wrote a logger that could run arbitrary code, then were surprised when attackers figured out how to run arbitrary code. It isn't a language problem, it is a developer practices problem. Developers code like security isn't a thing then are confused when their programs aren't secure.

alcover 4y ago
It isn't a language problem Exactly. This flamy sub-thread has no point here.
kelnos 4y ago
> It isn't a language problem, it is a developer practices problem. Developers code like security isn't a thing then are confused when their programs aren't secure. I'd prefer that the "fix" for this isn't "require that millions of developers around the world all change their behavior, and never screw up in the future". Languages can still protect against these sorts of bugs. Effect systems can describe as a part of the type system or function signature what kinds of things a function can do. For example, you could have a logging function where you know that the only side-effect is that it can write to stdout or stderr, or a file. Running arbitrary commands would not be allowed, and would cause the program to fail to compile. As a real-world example, I've used the Slick SQL library in Scala, and the query type has a type parameter for whether the query is an read or a write. It's easy to build a simple abstraction on top of your data layer to never allow a write to go through, for example, if that's something that's useful to prevent bugs. I think one thing I did with that was set things up so callers could not accidentally write to MySQL replicas; only reads could go to them, and writes had to go to the primaries. Granted, it takes discipline to build and use such a system, especially one that has such fine-grained effects. (I would expect most are more like a binary "does not do I/O" or "does I/O".)
- stonemetal12 4y ago
  The issue is like SQL Injection. Much like SQL Injection protection the logger needs to separate "active" strings vs attacker controlled "data" strings. It is pretty easy to design boring Java types that solve the issue. The only problem is they didn't. Unless this effects system somehow forces them to not do something dumb, we will end up with a logger that has effects set to "does everything under the sun", and a similar bug.

alcover 4y ago

It isn't a language problem Exactly. This flamy sub-thread has no point here.

kelnos 4y ago

> It isn't a language problem, it is a developer practices problem. Developers code like security isn't a thing then are confused when their programs aren't secure. I'd prefer that the "fix" for this isn't "require that millions of developers around the world all change their behavior, and never screw up in the future". Languages can still protect against these sorts of bugs. Effect systems can describe as a part of the type system or function signature what kinds of things a function can do. For example, you could have a logging function where you know that the only side-effect is that it can write to stdout or stderr, or a file. Running arbitrary commands would not be allowed, and would cause the program to fail to compile. As a real-world example, I've used the Slick SQL library in Scala, and the query type has a type parameter for whether the query is an read or a write. It's easy to build a simple abstraction on top of your data layer to never allow a write to go through, for example, if that's something that's useful to prevent bugs. I think one thing I did with that was set things up so callers could not accidentally write to MySQL replicas; only reads could go to them, and writes had to go to the primaries. Granted, it takes discipline to build and use such a system, especially one that has such fine-grained effects. (I would expect most are more like a binary "does not do I/O" or "does I/O".)

stonemetal12 4y ago
The issue is like SQL Injection. Much like SQL Injection protection the logger needs to separate "active" strings vs attacker controlled "data" strings. It is pretty easy to design boring Java types that solve the issue. The only problem is they didn't. Unless this effects system somehow forces them to not do something dumb, we will end up with a logger that has effects set to "does everything under the sun", and a similar bug.