31–40 of 139 posts
This seems like a big deal: One thing to note: this will be the last version of OpenBSD to be pressed on CD. The project will now focus on internet-only distribution, giving much more flexibility in the release schedule.
It does? I was under the impression the only reason anyone still did that was to give something physical to donators.
This seems like a big deal: One thing to note: this will be the last version of OpenBSD to be pressed on CD. The project will now focus on internet-only distribution, giving much more flexibility in the release schedule.
It does? I was under the impression the only reason anyone still did that was to give something physical to donators.
I love this defense in depth, buried in the release notes... https://www.openbsd.org/60.html
Farewell sparc32. You will be missed by the retrocomputing geeks.
Talking about security, I'm hoping for a bound-checking memory-safe C compiler to eventually made it into something like OpenBSD or FreeBSD and be used by default for all ports and packages. Almost no software there would suffer from the overhead, and OpenBSD doesn't even promise or try to be very fast, it's a perfect place for it.
Talking about security, I'm hoping for a bound-checking memory-safe C compiler to eventually made it into something like OpenBSD or FreeBSD and be used by default for all ports and packages. Almost no software there would suffer from the overhead, and OpenBSD doesn't even promise or try to be very fast, it's a perfect place for it.
Lots of excellent CBA research comes from the CHERI project http://www.cl.cam.ac.uk/research/security/ctsrd/
However, they struggle to run lots of very routine C programs; its surprising how many normal programs you run happen to have been written in C and happen to rely on unions and memory unsafety etc!
For example, if you read http://www.cl.cam.ac.uk/research/security/ctsrd/pdfs/201503-... and look at Table 1, you'll see common programs and libraries such as libc and Python which cause trouble for 'memory-safe C'.
This seems like a big deal: One thing to note: this will be the last version of OpenBSD to be pressed on CD. The project will now focus on internet-only distribution, giving much more flexibility in the release schedule.
Earlier quoted context omitted.
Use mprotect(2) on the region of memory that the program wants to make executable. http://man.openbsd.org/OpenBSD-current/man2/mprotect.2 This is good portable programming practise anyway...
So they should create a writeable mmapping, write the code into it, then change it to W^X using mprotect? How does this stop an attacker doing the same via ROP? ADDED: The approach that comes to my mind is that they could have two processes. One process has the sourcecode, and pages where it can write code. The other process can execute the code. The code updates performance counters which the JITing process can read…
Earlier quoted context omitted.
It does? I was under the impression the only reason anyone still did that was to give something physical to donators.
CDs are read-only, whereas a USB stick has (generally insecure) firmware that can be modified. So in a setting where the user is concerned about persistent USB malware, it can make sense to use them. It's a niche concern of course, but I suspect it's a little bit more common in the OpenBSD community than in many others. Of course it shouldn't be too hard for those users to build their own install boot CDs with the ta…