Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A capability-safe language would have minimized the Log4j vulnerability

justinpombrio.net

Post reply on HN
Print view View original

131–140 of 158 posts

Re: A capability-safe language would have minimized the Log4j vulnerability

#131

Post by Zababa »

continuational wrote: post #126
Zababa wrote: post #117

Earlier quoted context omitted.

Do you have more to share, like resources about capability-safe languages, or your ongoing work? > This also means that object capabilities aren't "colored" like async/await, monads, or other effect systems. That's interesting. How does that work? Is it by passing around a value from your main function to the functions that need it?

> Do you have more to share, like resources about capability-safe languages, or your ongoing work? I can share an example from the main function of the self hosting Firefly compiler [1]: main(system: System): Unit { ... let fs = system.files() if(fs.exists(tempPath)) { deleteDirectory(fs, tempPath) } ... } deleteDirectory(fs: FileSystem, outputFile: String): Unit { fs.list(outputFile).each { file => if(fs.isDirectory…

Thank you for the example, that helps a lot. So for example, when you write a library that need capabilities, you would write it using dependency (capability?) injection, and then the main program would have to pass an object with that capability for the code to work? And I see what you mean by "they are just plain values, and require nothing special from the type system", as long as you restrict what part of the program can produce a System or a FileSystem, you can just use plain typechecking.

Re: A capability-safe language would have minimized the Log4j vulnerability

#133

Post by samus »

DarkmSparks wrote: post #119
fiddlerwoaroof wrote: post #63

Earlier quoted context omitted.

This is more like ACLs, which are a completely different paradigm from capability-based security. An ACL system is based around specifying permissions for actions and such, whereas capability systems are based around reifying authority in an unforgeable way and passing the resulting tokens around.

I don't see the difference between passing tokens around and inheriting a security manager that can only have permissions and capabilities revoked?

The former is explicit, and an IDE can help with highlighting unused ones. The latter is difficult to audit because the code that uses relevant APIs is disconnected from the privilege-enforcing mechanism. It's either some sort of abstract policy framework or explicit privilege dropping

Re: A capability-safe language would have minimized the Log4j vulnerability

#134

Post by samus »

thrower123 wrote: post #120
DarkmSparks wrote: post #21

Personally I wonder whether anyone actually used log4j willingly or just because its generally used by all the apache projects and they wont start without it. With a healthy dose of "use the latest versions" mentality. I checked back and all my java code was still running log4j 1.1, and removing it has been on the todo list ever since it needed linking. You should be checking all your 3rd party source code, "capabili…

Same, all of our Java projects were using 1.X log4j, and have been for years and years without issue. Ironically, all of this scrutiny on the problems of the 2.X releases has forced us to agree to update from those rather dumb, safer builds to the latest releases, so that we'll have to be on the treadmill.

Log4j 1.x contains vulnerabilities and errors that were never addressed because it was declared end-of-life in 2015 and the Apache project has stopped supporting it!

https://logging.apache.org/log4j/1.2/index.html

https://www.cvedetails.com/cve/CVE-2019-17571/

Re: A capability-safe language would have minimized the Log4j vulnerability

#135

Post by samus »

Jweb_Guru wrote: post #20
vsareto wrote: post #17

Earlier quoted context omitted.

I don't think that's particularly useful though. A program with requirements like that seems more likely to be split up into two independent pieces.

But that's not at all the case in practice. Logging is intertwined with other program functionality.

Most logging libraries are facades over a concrete implementation. And there exist adapters for those that aren't. One could easily provide one that pipes the log stream to a child process that drops privileges and is restricted down by the OS. This will probably entail a performance penalty, but it could be worth it. It would be nice to have such a capability in-process though.

Re: A capability-safe language would have minimized the Log4j vulnerability

#136

Post by samus »

vsareto wrote: post #18
yjftsjthsd-h wrote: post #12

Earlier quoted context omitted.

Programming language can know more about the program's (intended) state at any given time. The OS can/should frequently be involved, but even then you're frequently doing something like pledge() from the program to let the OS know when/how to restrict you. Doing it totally externally, like SELinux does, is valuable but coarser-grained.

Can you not use network namespaces on Linux to give a process its own restricted network device and then filter that traffic?

The Linux kernel developers don't recommend using namespaces for security, but only for access control (the two are not the same!) because it's a relatively recent concept and the syscall interfaces and semantics are huge and subtle. Dedicated user accounts together with firewall rules are a better idea IMHO.

Re: A capability-safe language would have minimized the Log4j vulnerability

#137

Post by samus »

adfhadfignio wrote: post #14

Java has actually had this built in for a long time now. A SecurityManager allows you to restrict access to things like the filesystem and the network (and whatever else you want). I have never seen it used in a real codebase. https://docs.oracle.com/javase/tutorial/essential/environmen...

The security manager represents a flawed way to do it. It tries to catch up and restrict an application after it already has access to the releveant APIs. Forget to restrict just one API, and the sandbox can be escaped. Usually, the integration with the security manager requires intimate knowledge of the application.

Javascript follows a better approach because it has a small core API. All other APIs have to be explicitly injected and permitted by the host program.

Re: A capability-safe language would have minimized the Log4j vulnerability

#138

Post by samus »

jrockway wrote: post #29
the_arun wrote: post #10

Ideally all egress network connections should go via NAT Gateway & filters at NAT Gateway should have policies to say which request can go out. Failures do happen in programming, we need to have better guardrails ensuring security.

What sort of software are you using for the NAT gateways? (I know that's an AWS term, but not what I'm looking for. I've used that to provide a consistent outbound IP for production traffic so that upstream providers can allowlist an IP to talk to their API. Dumb security model when TLS client certificates exist, but... easy to set up I guess.) I've always wanted to defend against the attack where an application rout…

There is Blue Coat. The technology to MITM TLS connections is widespread, but I'd recommend against it. You would create a single point of failure for your whole infrastructure and a prime attack target. Also, if the proxy fails to correctly validate the TLS connection, every service will end up talking to the wrong endpoints.

Possible alternative: a dedicated API facade that forwards to the real APIs, and blocking of all other connections. There might be a tool that generates one from Swagger specifications. Also, require a client certificate or a password for each service. This way, you get centralized logging and access control without breaking TLS.

Re: A capability-safe language would have minimized the Log4j vulnerability

#139

Post by continuational »

Zababa wrote: post #131
continuational wrote: post #126

Earlier quoted context omitted.

> Do you have more to share, like resources about capability-safe languages, or your ongoing work? I can share an example from the main function of the self hosting Firefly compiler [1]: main(system: System): Unit { ... let fs = system.files() if(fs.exists(tempPath)) { deleteDirectory(fs, tempPath) } ... } deleteDirectory(fs: FileSystem, outputFile: String): Unit { fs.list(outputFile).each { file => if(fs.isDirectory…

Thank you for the example, that helps a lot. So for example, when you write a library that need capabilities, you would write it using dependency (capability?) injection, and then the main program would have to pass an object with that capability for the code to work? And I see what you mean by "they are just plain values, and require nothing special from the type system", as long as you restrict what part of the pro…

Yes, dependency injection (without DI frameworks) is pretty much what it is! Just taken a bit further to the logical conclusion.

I would point to an online resource, but honestly I haven't run across any that does justice to the simplicity of the concept.

Re: A capability-safe language would have minimized the Log4j vulnerability

#140

Post by kragen »

mlinksva wrote: post #53

https://fossandcrafts.org/episodes/20-hygiene-for-a-computin... does a great job of introducing capabilities in an easy to understand manner.

Thanks, Mike. This kind of introductory material is clearly needed in this thread!
Post reply on HN