Dependency Confusion: How I Hacked Into Apple, Microsoft and Other Companies • Hacker News Board

Re: Dependency Confusion: How I Hacked Into Apple, Microsoft and Other Companies

#371

Post by nmadden » Thu, Feb 11, 2021, 7:48 AM UTC

mike_hearn wrote: post #325

nmadden wrote: post #319

Earlier quoted context omitted.

Oracle’s own secure coding guidelines for Java [1] actually now recommend adopting a capability-based approach rather than relying on SecurityManager: > FUNDAMENTALS-5: Minimise the number of permission checks Java is primarily an object-capability language. SecurityManager checks should be considered a last resort. (Note: quite a lot of Java’s standard library is not designed along object-capability lines so you sho…

They are not in tension. The Java security architecture is a mix of capability and module-level security. It's probably worth posting a quick refresher. The system is old but people don't use it much these days, and the documentation isn't that good. At one point I wrote a small JavaFX PDF viewer that sandboxed the PDF rendering code, to learn the system. I lost the source code apparently, but the hard part wasn't co…

The File example is a good illustration of why Java is _not_ a capability-secure language. Every File object in Java has a getParentFile() method that allows you to navigate up the hierarchy right to the root and then from there access every file on the filesystem. Java’s standard library is full of these kinds of design flaws. So in practice you can only apply capability-based thinking to small subsets of a codebase and have to fallback on the (much weaker) stack walking checks if you want strong isolation.

The problem with Java’s stack walking is that it is too complex and too easy to find privileged code that can be coaxed into performing unintended operations. There are plenty of old write ups of Java sandbox bypass bugs due to this, eg http://benmmurphy.github.io/blog/2015/10/21/zdi-13-075-2013-...

Re: Dependency Confusion: How I Hacked Into Apple, Microsoft and Other Companies

#372

Post by saagarjha » Thu, Feb 11, 2021, 8:09 AM UTC

nmadden wrote: post #371

mike_hearn wrote: post #325

Earlier quoted context omitted.

They are not in tension. The Java security architecture is a mix of capability and module-level security. It's probably worth posting a quick refresher. The system is old but people don't use it much these days, and the documentation isn't that good. At one point I wrote a small JavaFX PDF viewer that sandboxed the PDF rendering code, to learn the system. I lost the source code apparently, but the hard part wasn't co…

The File example is a good illustration of why Java is _not_ a capability-secure language. Every File object in Java has a getParentFile() method that allows you to navigate up the hierarchy right to the root and then from there access every file on the filesystem. Java’s standard library is full of these kinds of design flaws. So in practice you can only apply capability-based thinking to small subsets of a codebase…

Escaping the VM via an out-of-bounds write doesn't really show that stack walking is broken :/

Re: Dependency Confusion: How I Hacked Into Apple, Microsoft and Other Companies

#373

Post by saagarjha » Thu, Feb 11, 2021, 8:15 AM UTC

jrochkind1 wrote: post #272

mstipetic wrote: post #219

Earlier quoted context omitted.

Unless it's a part of the standard library included with the language, nobody gets it. There has to be some designation before the name. It's not only node, python also does things like that

I don't understand how a designation in front of the name solves anything. The designation is basically just a name itself, you've just made it a two-part name, and a requirement that all names have two parts. ok, so?

The first part is going to be your name.

Re: Dependency Confusion: How I Hacked Into Apple, Microsoft and Other Companies

#374

Post by nmadden » Thu, Feb 11, 2021, 8:52 AM UTC

saagarjha wrote: post #372

nmadden wrote: post #371

Earlier quoted context omitted.

The File example is a good illustration of why Java is _not_ a capability-secure language. Every File object in Java has a getParentFile() method that allows you to navigate up the hierarchy right to the root and then from there access every file on the filesystem. Java’s standard library is full of these kinds of design flaws. So in practice you can only apply capability-based thinking to small subsets of a codebase…

Escaping the VM via an out-of-bounds write doesn't really show that stack walking is broken :/

That’s just the first example. As the author of that series writes, most of the exploits are not due to memory corruption. Most are confused deputy attacks where privileged code can be tricked into performing dangerous operations.

Re: Dependency Confusion: How I Hacked Into Apple, Microsoft and Other Companies

#375

Post by saagarjha » Thu, Feb 11, 2021, 9:23 AM UTC

nmadden wrote: post #374

saagarjha wrote: post #372

Earlier quoted context omitted.

Escaping the VM via an out-of-bounds write doesn't really show that stack walking is broken :/

That’s just the first example. As the author of that series writes, most of the exploits are not due to memory corruption. Most are confused deputy attacks where privileged code can be tricked into performing dangerous operations.

Oh, I don't doubt it. I'm just saying that the particular example you linked wasn't that great.

Re: Dependency Confusion: How I Hacked Into Apple, Microsoft and Other Companies

#376

Post by [deleted] » Thu, Feb 11, 2021, 11:39 AM UTC

nmadden wrote: post #370

ryukafalz wrote: post #362

Earlier quoted context omitted.

Maybe I'm missing something about the use case, but I'm not sure I quite follow. Sure, something needs to have permission to use the higher level of privilege. On your typical POSIX OS, your program is probably born with the ability to create arbitrary TCP/UDP sockets by default; on a capability OS, maybe you've explicitly provided it with access to your network stack. Regardless, at the entry point to your program y…

Exactly. What usually happens in capability systems is that the main() method gets all the capabilities (or whatever capabilities the user allowed it) and then does dependency injection to distribute those to other components. No need for complex stack-based authentication or policy rule evaluation. Indeed, if you look at the history of Java sandbox escapes they are largely confused deputy attacks: some privileged co…

[deleted]

Re: Dependency Confusion: How I Hacked Into Apple, Microsoft and Other Companies

#377

Post by beermonster » Thu, Feb 11, 2021, 11:48 AM UTC

pabs3 wrote: post #360

beermonster wrote: post #214

Earlier quoted context omitted.

Apt supports TLS via apt-transport-https (as you are probably already aware) but I don't think it's default in either Debian nor (X)Ubuntu derivatives. I'd like to know why TBH. The packages themselves are signed though, so I guess the risk is now on server authenticity as opposed to package integrity.

The packages are not signed, but there is a hash chain from the signed Release files through to the packages themselves.

Yes you are right, I stand corrected.

Here is an explanation of the process under 'The current scheme for package signature checks' at the following url

https://www.debian.org/doc/manuals/securing-debian-manual/de....

Re: Dependency Confusion: How I Hacked Into Apple, Microsoft and Other Companies

#378

Post by beermonster » Thu, Feb 11, 2021, 11:51 AM UTC

noisenotsignal wrote: post #330

beermonster wrote: post #172

Earlier quoted context omitted.

I think image signing support (or at least was) is not as good as it can be. It would be nice if more images were signed by publishers and verification performed by default. Even then, that only gives you a stronger indication that the image hasn't been altered since it was signed by the image author at any point after it being signed. However it is not a guarantee that the source produced the binary content. It's al…

You can enable client enforcement of Docker Content Trust [1] so that all images pulled via tag must be signed. Whether people are actually signing their images is a different question that I don't know the answer to. [1] - https://docs.docker.com/engine/security/trust/#client-enforc...

Presumably that approach works best in conjunction with third-party publishers publishing signed images?

Very useful for your own images that you publish in your registry though.

Re: Dependency Confusion: How I Hacked Into Apple, Microsoft and Other Companies

#379

Post by mike_hearn » Thu, Feb 11, 2021, 12:03 PM UTC

nmadden wrote: post #371

mike_hearn wrote: post #325

Earlier quoted context omitted.

They are not in tension. The Java security architecture is a mix of capability and module-level security. It's probably worth posting a quick refresher. The system is old but people don't use it much these days, and the documentation isn't that good. At one point I wrote a small JavaFX PDF viewer that sandboxed the PDF rendering code, to learn the system. I lost the source code apparently, but the hard part wasn't co…

The File example is a good illustration of why Java is _not_ a capability-secure language. Every File object in Java has a getParentFile() method that allows you to navigate up the hierarchy right to the root and then from there access every file on the filesystem. Java’s standard library is full of these kinds of design flaws. So in practice you can only apply capability-based thinking to small subsets of a codebase…

I shouldn't have used File as an example, that was confusing. I was trying to explain capabilities and stack walking in an abstract sense but was also using Java as a concrete example. Big mistake.

You're right that java.io.File isn't a capability. It just represents a file path with a few utility methods to list files, and therefore does a stack walk when you try to access the filesystem. A FileChannel is a file capability in the sense I meant above, because it represents an opened file, not a path. There's an access check once, when it's opened, and then the rest of the time there aren't any stack walks.

It's a pity that Ben Murphy didn't write up all his bugs. There are only two listed there. A few patterns cropped up repeatedly in the old sandbox escapes:

1. Accessing internal code you weren't meant to have access to. Often, some sorts of privileged pseudo-reflection API. Fixing this is the goal of Jigsaw.

2. Serialization acting as a back door, allowing the internal private state of classes to be tampered with. Serialization security has been improved with time and they're now working on a feature that will make it harder to screw this up, by allowing serialization to use normal constructors instead of this ad-hoc form of reflection.

3. Overly general frameworks that allowed attackers to construct nearly arbitrary programs out of privileged objects by chaining them together (this crops up in gadget attacks too). There's probably no platform level fix for this, people just have to be aware of the risks when working in sandboxed context.

I don't think a pure capability language is workable, to be honest. At least not at a large scale. In the purest sense you need a god object passed into the start of your program which vends all possible capabilities, and every library would require the user to construct and pass in all resources it needs externally, including things it might possibly need. And that code isn't easily modularised because you can't just use helpers provided by the library itself: that's the very same code you're trying to sandbox. There's no good way to make that usable or extensible. The combination of stack walking and capabilities lets you find the right balance in terms of API design between simplicity of use and sandbox simplicity.

Re: Dependency Confusion: How I Hacked Into Apple, Microsoft and Other Companies

#380

Post by mike_hearn » Thu, Feb 11, 2021, 12:06 PM UTC

WatchDog wrote: post #328

eecc wrote: post #223

Earlier quoted context omitted.

Uh, well the original developers of the Sun JVM didn’t do such a bad job after all when designing it: https://docs.oracle.com/javase/7/docs/technotes/guides/secur...

Javas security manager system, is usually not in effect for the majority of use cases. While maven/grade dependencies, can't run code on installation, generally once the application is ran/tested, it will be with full user permissions, not under a security manager. The security manager is an additional layer of security that most languages don't have, however Java applets have shown it to be full of holes and general…

There have been hundreds, maybe thousands of local privilege escalation vulnerabilities on Linux. People still find bugs in basic programs like sudo that have been there for decades. Still, nobody would ever suggest that Linux should have the same security approach as Windows 95 or that it's generally unsuitable for running code you didn't write!

Sandboxing code is hard, regardless of what language, runtime or operating system approach you use.