News for hackers. Stuff that matters.
Re:Unikernels are secure by meson2k on Monday July 10, 2017 @12:22PM (#14737317)
> Good luck guessing that address. Our own unikernel, IncludeOS, randomizes addresses at each build, so even with access to source code you still don’t know the memory layout.

"There is one mortal sin in computer security (or by the way, in any kind of security) that is feeling safe. It’s just a variation of pride to be true, but it’s very deadly. Blindly trusting a protection technology is an extreme error."

Read up on DEP. Randomizing function addresses at each build is useless when it comes to attack mitigation. You need to randomize addresses at each execution.

Re:Unikernels are secure by KirinDave on Monday July 10, 2017 @03:02PM (#14738694)
Pardon me, but this seems pretty different from the use cases of DEP. Perhaps you'd like to expound further on this.

Imagine a standard webapp deployed via CI. Each time any feature is shipped the entire layout is randomized and then deployed. While a redundant system will have multiple copies with an identical layout, that layout will rotate. If required, a CI process could rebuild the system into N parallel groups with N different layouts (your degree of paranoia is the salt to taste here).

Given that these systems are frequently rebuilt with each deploy it seems nearly identical to me in practice to a relink-on-run.

Re:Unikernels are secure by throwaway2048 on Monday July 10, 2017 @08:19PM (#14740701)
lots of binaries are distributed as compiled, thats one of the attractions of a unikernel you can just hand people a VM image of whatever the hell you want.

In regards to what could be rebuilt, computer security is plagued with "coulds". What matters is what is done.

Re:Unikernels are secure by KirinDave on Monday July 10, 2017 @11:06PM (#14741313)
This is a tricky argument you make because it's so asynmetrical. You can essentially cherry pick the worst opsec and the most dedicated attacker and then use it to discount an entire technique.

I will not play this "Use OpenBSD because it has a new technique that is fashionable" game that I know is being played.

Custom baremetal custon built VMs is not really in the business of distribution appliance images. That's Docker. Different use case. So what IS done is a workflow to rebuild these images when they change.

And that's often. Their HTTP routing table is literally baked into the image. They're not "reusable" for the most part.

Re:Unikernels are secure by staticassertion on Tuesday July 11, 2017 @07:26AM (#14743214)
DEP isn't relevant. If you're compiling your own kernel this is a completely viable security technique.

Where it fails is in distros. AFAIK most linux distros do something similar (based on Grsecurity patches) but it's useless because... they then distribute the binary, with everything necessary to get addresses.

But if you're distributing it internally/ it's a secret, yeah, you're going to benefit from that.

Re:Unikernels are secure by agumonkey on Monday July 10, 2017 @12:29PM (#14737401)
is linux randomizing is per exec ?

ps: BSD have started to randomize at boot time, fun times

Re:Unikernels are secure by geofft on Monday July 10, 2017 @12:32PM (#14737425)
> is linux randomizing is per exec ?

Not entirely sure what you're meaning to ask, but yes, Linux does KASLR and tries very hard not to leak pointer addresses from the running kernel to unprivileged userspace:

https://lwn.net/Articles/569635/

It's been enabled by default since the upstream 4.12 kernel, and usually well before that in distros.

Re:Unikernels are secure by _joel on Monday July 10, 2017 @12:55PM (#14737635)
KALSR's not the same as ASLR (although ideologically related). ALSR has been around for a good number of years in userspace via randomize_va_space sysctl

(edit I presume that's what the poster above mentioned re: per exec)

Re:Unikernels are secure by agumonkey on Monday July 10, 2017 @01:04PM (#14737712)
yes ALSR, sorry, acronym fail on my part. So ALSR does randomize bindings on each execution ?
Re:Unikernels are secure by majewsky on Monday July 10, 2017 @01:16PM (#14737824)
Yes. If I run e.g. `ldd /bin/bash` multiple times, it shows different memory addresses each time. That's ASLR.
Re:Unikernels are secure by strcat on Monday July 10, 2017 @05:02PM (#14739634)
cat /proc/self/maps is a better way to see that. If it's built with PIE, the executable base is randomized. Some distributions use full ASLR across the board (Alpine, Android, ChromeOS, Hardened Gentoo) while others don't yet enable PIE globally or have only recently started and it isn't all pushed out yet (OpenSUSE, Fedora, Debian).
Re:Unikernels are secure by language on Monday July 10, 2017 @02:48PM (#14738594)
Also worth mentioning that `ldd` only demonstrates how shared libraries are mmap'ed at randomized locations. Stack and heap allocations are also randomized at execution time.
Re:Unikernels are secure by agumonkey on Monday July 10, 2017 @02:45PM (#14738569)
I never bothered to check, what a m... I am. Thanks a lot :)
Re:Unikernels are secure by cyphar on Tuesday July 11, 2017 @02:28AM (#14742007)
Linux randomises userspace executables on per-exec (check out /proc/self/maps).

BSD also does the same for userspace, but their new feature is that they randomise the kernel per-boot (by re-linking the objects). This is a far stronger form of kASLR (though I think they're calling it something else because it requires relinking the kernel binary).

Even Windows does this well.

Bragging about boot-time ASLR seems quite odd for an article like this, given that traditional operating systems have had similar (and in many ways superior) features like this for more than a decade (PaX introduced ASLR in Linux in 2001, OpenBSD had it by-default in 2003, and Linux shipped it by-default in 2005).