[meson2k]

> 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.

[KirinDave]

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.

[throwaway2048]

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.

[KirinDave]

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.

[staticassertion]

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.

[agumonkey]

is linux randomizing is per exec ?

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

[geofft]

> 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.

[_joel]

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)

[agumonkey]

yes ALSR, sorry, acronym fail on my part. So ALSR does randomize bindings on each execution ?

[majewsky]

Yes. If I run e.g. `ldd /bin/bash` multiple times, it shows different memory addresses each time. That's ASLR.

[strcat]

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).

[language]

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.

[agumonkey]

I never bothered to check, what a m... I am. Thanks a lot :)

[cyphar]

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).