It's good that they have their priorities straight. No more Linux binaries support (who need compatibility anyways?), but instead you get 5 songs sung by the project leader.
[deleted]
OpenBSD 6.0 released
71–80 of 139 posts
Re: OpenBSD 6.0 released
#72I've never really had a separate /usr/local partition, but it looks like that might not be such a bad idea given the upgrade guide: https://www.openbsd.org/faq/upgrade60.html
Re: OpenBSD 6.0 released
#73It's good that they have their priorities straight. No more Linux binaries support (who need compatibility anyways?), but instead you get 5 songs sung by the project leader.
[deleted]
Re: OpenBSD 6.0 released
#74"To deter code reuse exploits, rc(8) re-links libc.so on startup, placing the objects in a random order." I love this defense in depth, buried in the release notes... https://www.openbsd.org/60.html
This is pretty much useless. Attackers have moved on to using information leaks in order to determine memory layout and placement of objects. So in practice, this doesn't really deter anything. Information leaks are everywhere.
Without this patch, using an information leak to bypass ASLR would be as simple as leaking any address in libc (__libc_start_main is often convenient since it's where main returns to when the progam ends, and hence is already on the stack), subtracting the (fixed, public) offset from the leak to calculate the base address libc was loaded at, and adding the (again fixed and public) offset from libc's base to some useful function (e.g. system(3)).
With this patch, the order of symbols are randomized every boot, so the offsets that were previously fixed and public aren't.
It's probably still possible, if you have multiple adaptive memory reads, to traverse the datastructures that legitimate programs use to find the order of the symbols, but a) not all information leaks can be used to read arbitrary addresses multiple times, and b) the traversal code becomes more complicated for the attacker to {write,maintain} relative to the simple arithmetic that was previously possible.
The above analysis is for remote exploits, local privilege escalation exploits can just read libc to determine the order (since it's re-linked on boot, not per process).
Re: OpenBSD 6.0 released
#75Earlier quoted context omitted.
This is pretty much useless. Attackers have moved on to using information leaks in order to determine memory layout and placement of objects. So in practice, this doesn't really deter anything. Information leaks are everywhere.
I don't know why you're being down voted. We've had ASLR in Linux for years and various attacks have been successful. The string format attack is the one I remember most clearly which basically renders ASLR useless.
Pretty much any security measure in isolation can be bypassed. So you need to stack as many as are reasonable on top of each other to limit the attacker's toolkit.
This change is basically free and makes certain things more difficult for attackers, so why not?
Re: OpenBSD 6.0 released
#76Earlier quoted context omitted.
This is pretty much useless. Attackers have moved on to using information leaks in order to determine memory layout and placement of objects. So in practice, this doesn't really deter anything. Information leaks are everywhere.
I don't know why you're being down voted. We've had ASLR in Linux for years and various attacks have been successful. The string format attack is the one I remember most clearly which basically renders ASLR useless.
Attacker-controlled format strings are very convenient bugs, but they can't do everything.
Consider the program:
int main() {
char buf[20];
fgets(buf, sizeof buf, stdin);
printf(buf);
return 0;
}
A significant limitation of the vulnerability in the above program is the attacker can't, in a single execution of the program, read a value, then do computations on it locally, then write a value based on those computations. This flexibility is needed in order to bypass ASLR.
Re: OpenBSD 6.0 released
#77I've never really had a separate /usr/local partition, but it looks like that might not be such a bad idea given the upgrade guide: https://www.openbsd.org/faq/upgrade60.html
I like having separate partitions (or slices) for everything. The guy who introduced me to UNIX did it so he could mount certain filesystems "ro" or "noexec". He also told me that partitioning can help avoid inode exhaustion but I really doubt that is an issue with modern filesystems.
I still partition with NetBSD. It just feels right; even if not necessary.
Re: OpenBSD 6.0 released
#78I've never really had a separate /usr/local partition, but it looks like that might not be such a bad idea given the upgrade guide: https://www.openbsd.org/faq/upgrade60.html
I like having separate partitions (or slices) for everything. The guy who introduced me to UNIX did it so he could mount certain filesystems "ro" or "noexec". He also told me that partitioning can help avoid inode exhaustion but I really doubt that is an issue with modern filesystems. I still partition with NetBSD. It just feels right; even if not necessary.
Oh, I partition too, but I do /, /usr, /var, /var/log, /home, /tmp, /opt (yeah, yeah, I know), and then anything server specific (mail, maybe www). I just don't do the /usr/local.
Re: OpenBSD 6.0 released
#79I've never really had a separate /usr/local partition, but it looks like that might not be such a bad idea given the upgrade guide: https://www.openbsd.org/faq/upgrade60.html
I like having separate partitions (or slices) for everything. The guy who introduced me to UNIX did it so he could mount certain filesystems "ro" or "noexec". He also told me that partitioning can help avoid inode exhaustion but I really doubt that is an issue with modern filesystems. I still partition with NetBSD. It just feels right; even if not necessary.
I never run out of disk space, but I frequently run out of inodes. It's definitely still an issue. And if you don't stop to think about when you're creating your file system, it tends to bite you in the arse at a later date.
Re: OpenBSD 6.0 released
#80For those of you who are looking at a reason to play around with openBSD, there might be some progress at getting it to run at the Raspberry pi 2 and 3: http://marc.info/?l=openbsd-cvs&m=147059203101111&w=2 Probably not going to happen, but it runs on some other ARM7 SBCs. Mine is running FreeBSD currently, but where is the geek cred in that?
this is currently being worked on as I type this reply :)
[deleted]