Earlier quoted context omitted.
Too bad they don't accept peer-to-peer electronic cash
> Bitcoin donation via BitPay: The OpenBSD Foundation can accept donations in BTC via BitPay
OpenBSD may soon gain further memory protections: immutable userland mappings
61–70 of 72 posts
Re: OpenBSD may soon gain further memory protections: immutable userland mappings
#62Earlier quoted context omitted.
OpenBSD does great work, but for the record OpenSSH started as a fork of the free SSH program developed by Tatu Ylönen; later versions of Ylönen's SSH were proprietary software offered by SSH Communications Security. https://en.wikipedia.org/wiki/OpenSSH
Realistically, OpenBSD completely reimplemented protocol 2 themselves. Since nobody uses protocol 1 anymore, very little of the original code from Tatu Ylönen remains in operation with default settings. ps I have had to use the SSH commercial release under VMS, and the compatibilities with OpenSSH are quite unpleasant.
Re: OpenBSD may soon gain further memory protections: immutable userland mappings
#63Earlier quoted context omitted.
> You mean _start()'s stack pointer. Right, yeah. > It would probably break the ANSI C standard though if you can't modify argv and environ though. AFAIK it would also break setproctitle(), unless my memory is off that works by just writing over the argv space. On the plus side, on Linux /proc/ /environ is a snapshot created at the time of execve() and kept by the kernel, nothing other than execve() can change it (do…
> On the plus side, on Linux /proc/ /environ is a snapshot created at the time of execve() and kept by the kernel, nothing other than execve() can change it (don't quote me on this, I'm only 90% sure.) prctl(PR_SET_MM_ENV_{START,END}) will change the contents of /proc/ /environ. From what it looks like in Linux's source code, twiddling the bits at the base of the stack will also cause the procfs file to change--it se…
… but Thanks for removing a misconception of mine!
Re: OpenBSD may soon gain further memory protections: immutable userland mappings
#64Earlier quoted context omitted.
> You mean _start()'s stack pointer. Right, yeah. > It would probably break the ANSI C standard though if you can't modify argv and environ though. AFAIK it would also break setproctitle(), unless my memory is off that works by just writing over the argv space. On the plus side, on Linux /proc/ /environ is a snapshot created at the time of execve() and kept by the kernel, nothing other than execve() can change it (do…
No setproctitle on Linux. As far as I know you have to overwrite the argv space (and hopefully not also the environment space).
Re: OpenBSD may soon gain further memory protections: immutable userland mappings
#65Earlier quoted context omitted.
There used to be complaint from OpenBSD that large corporate users of OpenSSH weren't donating anything, so I sent them $100. Those days appear to be over. https://www.theregister.com/2015/07/08/microsoft_donates_to_...
Better than nothing but it's far from what the title describes as "rains cash". MS : $25k - $50k Google , FB : $10k - $25k For them, that's like saying "Hi". For the financial value the OpenBSD foundation is creating, that's a miniscule return.
Still, I haven't heard any recent complaint on fundraising goals.
Re: OpenBSD may soon gain further memory protections: immutable userland mappings
#66Earlier quoted context omitted.
Is the ROP gadget hardening OpenBSD does mostly useless tho? Can you elaborate?
The issue is largely that the OpenBSD authors don’t really seem to understand how actual ROP chains work, so their mitigations are tailored towards things that don’t actually match reality. For example, trapsled is meant to protect against sloppy/partial overwrites writes that take advantage of nops to slide to where attackers actually want to go. The problem is that using nop slides in a ROP chain is Not A Thing. Pe…
Re: OpenBSD may soon gain further memory protections: immutable userland mappings
#67Earlier quoted context omitted.
The ROP-gadget stuff hasn't migrated to any other kernels that I have seen. As I understand it, previous ROP-gadget hardening included compiler modifications on system/function call return, trap sleds, and some other stuff that I don't remember. This is on top of the kernel and library relink at every boot (to really make ASLR more potent). These modifications include a verification that the jump is in the stack, and…
This is because the ROP gadget hardening OpenBSD does is generally considered to be mostly useless by other kernels, which are moving to hardware-enforced control flow integrity instead.
Re: OpenBSD may soon gain further memory protections: immutable userland mappings
#68What exploit technique is this mitigating?
That’s always a good question to ask :) Seems like the claim is that it prevents exploits where you’d map libc executable and then spray code there. IMO if you have the ability to do this you usually have lost already but ¯\_(ツ)_/¯
Re: OpenBSD may soon gain further memory protections: immutable userland mappings
#69Earlier quoted context omitted.
The issue is largely that the OpenBSD authors don’t really seem to understand how actual ROP chains work, so their mitigations are tailored towards things that don’t actually match reality. For example, trapsled is meant to protect against sloppy/partial overwrites writes that take advantage of nops to slide to where attackers actually want to go. The problem is that using nop slides in a ROP chain is Not A Thing. Pe…
Thank you for taking the time to reply and explain things to me. I appreciate it. I've nothing else to add because I just wanted to know more.
Re: OpenBSD may soon gain further memory protections: immutable userland mappings
#70I was just discussing this sort of thing with some colleagues. Because the stack frame for main contains a bunch of other stuff - environment variables, cli args, etc - it makes it unreliable to try to instrument Linux systems and collect that information. A process can change its name, args, env, at any time. That sort of information is really helpful for forensics. Currently your only option is to pull data directl…
> a) I bet some insane userland processes fuck with their stacks What do you mean by "insane" here? In standard C you get char** argv, and the arguments live on the stack. I believe you are allowed to modify those cli arguments through the pointers, it is not undefined behavior.