Hacker Read top | best | new | newcomments | leaders | about | bookmarklet login

Sandboxing is mostly irrelevant to the log4j error. You'd have to tell the sandbox to turn off reflection, which isn't really feasible in Java. And that's because Java is so poorly designed that big libraries are all designed to use reflection to present an API they consider usable.

Compare that to a language designed well enough that reflection isn't necessary for good APIs, for instance.



view as:

Dunno if I agree that libraries need reflection. Some do, but primarily in the dependency injection and testing space.

That's not really where you'd expect RCE-problems.


Yeah, I should say where developers don't think they need to use reflection.

Like, the log4j thing came from (among other design errors) choosing to use reflection to look up filters for processing data during logging. Why would log4j's developers possibly think reflection is an appropriate tool for making filters available? Because it's the easy option in Java. Because it's the easy option, people are already comfortable with it in other libraries. Because it's easy and comfortable, it's what gets done.

Some languages make reflection much more difficult (or nearly impossible) and other APIs much easier. It's far more difficult to make that class of error in languages like that.


> big libraries are all designed to use reflection to present an API they consider usable.

whistles in python


Python has first-class type objects. That's not the same thing as writing:

  pickle._getattribute(__import__(package), path)
everywhere, which is basically how Java reflection works half the time. In Python, you'd have something like copyreg.dispatch_table, and have plugin modules that register themselves in the table at load-time – limiting your attack surface to the modules you expect to be attack surface, rather than every single package accessible to the JVM.

Legal | privacy