4 ms·

And then we'd have potential exploits both in the daemon and in the safe language runtime/compiler. There is no silver bullet for this. One just needs to keep

And then we'd have potential exploits both in the daemon and in the safe language runtime/compiler. There is no silver bullet for this. One just needs to keep on looking for exploits and keep on patching them. However there is a lot that can be improved on OpenSSL side. I hope they change their memory allocation strategy after this.

lazyjones 13y ago
> And then we'd have potential exploits both in the daemon and in the safe language runtime/compiler. Now we have exploits for libraries and runtimes that often allow access to arbitrary application data. If this functionality is in a separate process without such privileges, application data will be safe. > One just needs to keep on looking for exploits and keep on patching them. This approach hasn't worked in the past and will not work in the future either. Especially when we start with the existing, desolate and probably thoroughly compromised codebases.
- danielweber 13y ago
  Now we have exploits for libraries and runtimes that often allow access to arbitrary application data. If this functionality is in a separate process without such privileges, application data will be safe. This will prevent the prior vulnerability. Will it prevent the next one? Do you know what it won't make the next vulnerability worse? A year or two ago I had to deal with a bunch of people complaining that the embedded device my team was selling was vulnerable to BEAST, because their scanning tool told them it was. I wrote a long essay for the support team about how BEAST is exploited and it's really hard to do it against a limited purpose control GUI with no publicly routeable address, and this worked for about half the people who complained. For the others we had to turn on RC4, which may have been even worse, but now their tool wasn't complaining at them so they were happy, even though they may have been worse off. Thankfully my old team didn't rush to the new OpenSSL version so they got to avoid the past 48 hours being complete shit for them. There aren't clean answers. Like with financial regulation, what you do to make sure the last thing never happens again may create the next thing.
- sharpneli 13y ago
  > Now we have exploits for libraries and runtimes that often allow access to arbitrary application data. If this functionality is in a separate process without such privileges, application data will be safe. Even now if OpenSSL would not have made their own memory manager focusing on performance this bug would not have such major consequences. Frankly they should just accept performance penalties and make a memory manager that focuses on security. As an example all allocations should be from mmap so that any overflow will automatically segfault (with checks that one doesn't get continuous pages from the OS unmapping selectively to create disjoint areas). Every free should be a munmap etc. I do also agree that moving this to a separate process would be useful.
awj 13y ago
> And then we'd have potential exploits both in the daemon and in the safe language runtime/compiler. That doesn't make the idea futile, especially considering the current alternative. A language runtime focused on safety and a daemon that uses it for that purpose are going to present less of an attack surface than ifdef soup with custom malloc implementations and hand-managed buffer transfers.

lazyjones 13y ago

> And then we'd have potential exploits both in the daemon and in the safe language runtime/compiler. Now we have exploits for libraries and runtimes that often allow access to arbitrary application data. If this functionality is in a separate process without such privileges, application data will be safe. > One just needs to keep on looking for exploits and keep on patching them. This approach hasn't worked in the past and will not work in the future either. Especially when we start with the existing, desolate and probably thoroughly compromised codebases.

danielweber 13y ago
Now we have exploits for libraries and runtimes that often allow access to arbitrary application data. If this functionality is in a separate process without such privileges, application data will be safe. This will prevent the prior vulnerability. Will it prevent the next one? Do you know what it won't make the next vulnerability worse? A year or two ago I had to deal with a bunch of people complaining that the embedded device my team was selling was vulnerable to BEAST, because their scanning tool told them it was. I wrote a long essay for the support team about how BEAST is exploited and it's really hard to do it against a limited purpose control GUI with no publicly routeable address, and this worked for about half the people who complained. For the others we had to turn on RC4, which may have been even worse, but now their tool wasn't complaining at them so they were happy, even though they may have been worse off. Thankfully my old team didn't rush to the new OpenSSL version so they got to avoid the past 48 hours being complete shit for them. There aren't clean answers. Like with financial regulation, what you do to make sure the last thing never happens again may create the next thing.
sharpneli 13y ago
> Now we have exploits for libraries and runtimes that often allow access to arbitrary application data. If this functionality is in a separate process without such privileges, application data will be safe. Even now if OpenSSL would not have made their own memory manager focusing on performance this bug would not have such major consequences. Frankly they should just accept performance penalties and make a memory manager that focuses on security. As an example all allocations should be from mmap so that any overflow will automatically segfault (with checks that one doesn't get continuous pages from the OS unmapping selectively to create disjoint areas). Every free should be a munmap etc. I do also agree that moving this to a separate process would be useful.

awj 13y ago

> And then we'd have potential exploits both in the daemon and in the safe language runtime/compiler. That doesn't make the idea futile, especially considering the current alternative. A language runtime focused on safety and a daemon that uses it for that purpose are going to present less of an attack surface than ifdef soup with custom malloc implementations and hand-managed buffer transfers.