Comment by greenhouse_gas | Hacker News Reader

Comment by greenhouse_gas | Hacker News Reader

Parent Full thread

Small history of security:

First major security breech through buffer -overflow was in the late 80s.

So when Java came out, they played it "safe" - the language, despite having pointers will be absolutely safe. NullPointerExceptions and ArrayOutOfBoundsException will cause the program to crash rather than corrupting the stack.

Perfect.

Except it wasn't. It ended up being so "holy" that it's now banned in browsers.

So, everyone said to move to JS. Another "perfectly safe" language.

But it's too slow.

So JIT it.

Now it's no longer "perfectly safe".

Rinse and repeat.

And rust won't help here, because while the " compiler " can be guaranteed safe, the code it outputs can't (think of a C compiler written in Rust).

Maybe the solution isn't to rely on language (except for the Kernel) but to make of easy to spawn OS processes that simply have no rights to call any syscalls and limited amount of memory (or a white-listed amount of syscalls).

Take it like this:

Firefox (the browser) has full rights. It starts a process (which can only connect to the network to IP RemoteHost).

If process dies (for whatever reason) or takes too long, tell user that "sorry, sites broken".

Now, malicious code causes the attacker to run arbitrary code? Who cares? You can't overwrite the browser's code and can't break out.

The browser just has to ensure that its subprocess gives you good output.

Same with JS, CSS, or image libraries.

You're conflating the issues of running untrusted code with running trusted code on untrusted input. JS is untrusted code that you run on your computer. Your other examples generally do not fall into this camp.

Java being an allegedly safe server-side language has nothing to do with it being a very difficult language to sandbox when running untrusted code. It doesn't matter what language the malware I just downloaded was written in, because it's malware and it's running on my computer. What makes Java different from C in this case is that when I run a Java application on my server, I can be more confident in the fact that I will not have a buffer overflow, even when I expose the service to the entire internet.

>You're conflating the issues of running untrusted code with running trusted code on untrusted input. JS is untrusted code that you run on your computer. Your other examples generally do not fall into this camp.

No. The issue is that in C (or "release (not debug) rust" (someone here left a comment that rust programs in release mode don't check for array overflows)) untrusted input leads to untrusted code (through buffer-overflow).

So you can compromise a computer through a bug in imagemagick.

>Java being an allegedly safe server-side language has nothing to do with it being a very difficult language to sandbox when running untrusted code

Java was (in the 90s) advertised as safe client-side, hence applets.

No, release Rust does not do this. That is, the integer may overflow, but the buffer will not, unless you specifically go out of your way to use the unsafe unchecked access functions.

That's actually how many apps on macOS have worked for years. Anything that ships in the Mac App Store runs in a sandbox with limited privileges. In fact, every instance of an Open/Save panel on macOS run in a separate process to the main application and relay their visual appearance using XPC and NSRemoteView. It's pretty cool stuff!

That's also the direction Linux is heading with Flatpak and Flatpak portals.

I'm excited because there will finally be a reliable way for me to apply my preferred Open/Save dialogs to KDE and GTK+ apps alike. (It's being implemented at the toolkit level and you can run an app in Flatpak with sandboxing set to permit-all to get the portal hooking.)

> Maybe the solution isn't to rely on language (except for the Kernel) but to make of easy to spawn OS processes that simply have no rights to call any syscalls and limited amount of memory (or a white-listed amount of syscalls).

We have that [1] [2]. It's cumbersome to use, but it's based on the bpf JIT used for tcddump etc.

We also have a variety of other mechanisms you can combine with that to tie down a process. But even then it's hard to get this right in a way that's both performant and secure, because you have to protect every user every time, while for an attacker a very low success rate can still be worth it.

[1] https://www.kernel.org/doc/Documentation/prctl/seccomp_filte...

[2] https://wiki.mozilla.org/Security/Sandbox/Seccomp

This is ignoring the fact that sensitive data may actually be inside the (vulnerable, locked-down) process. Or checks inside the process may in some way be influenced (remember register_globals in PHP? This happens even when you execute PHP in a locked-down container).

A safe language greatly helps to prevent the sort of bug that compromises within-process security.

Reply on news.ycombinator.com