I found a certain irony in the title of this piece given that when I first opened the article, I was greeted with, "You've reached your article limit. Register to read up to three articles each week or subscribe now for just €20", and then I switched to incognito mode and defeated their security.
(I'm actually an Economist subscriber, I just wasn't logged in.)
It's strange that their website is so bad (lots and lots of ads, basically unusable without an ad-blocker) while their apps (in particular, Espresso) are a joy to use.
That does sort of invalidate the "things are starting to get better" part of the title.
It must be difficult to get better because new software comes out all the time, and old software stays around. So the attack surface grows. IoT really pushes that model hard. I know the firmware in my TV hasn't changed since I bought it, but the newer model of the same TV has different firmware.
I'd argue that these are lagging indicators. The code that's deployed and being exploited now was written years ago, using languages and tools developed decades ago.
If you read to the end of the article, it discusses recent DARPA projects that are addressing the tools and languages component. And most of this stuff is still in heavy development. Even assuming that we get it sorted out soon, it will still be years and years before most deployed software is built on these improved foundations.
So yes, things are starting to get better. But it will take a long time before we see the results.
Software defense techniques are getting more sophisticated and capable but software is getting far more complex compromising many of these defensive techniques. For instance JITs provide vital performance increases but require memory pages which are marked as execute and write which degrades the effectiveness of many memory corruption protections.
What we have achieved is that if you are willing to keep things simple and give up much of the modern world (e.g. JITs) you can build far more secure software than what was possible in the past. What we have done is extend the realm of the possible in both the direction of security and vulnerability (e.g. before TrustZone it wasn't possible to leverage TrustZone to exploit a kernel).
The idea is that the JITed code is executed much more often than it's (re)written, right?
So each time the JIT (re)compiles the code, it can call mprotect on the target page to allow writes and disable execution. Then after it's done, it calls mprotect again to disable writes and allow execute.
Is it fair to say that JITs are usually restricted to memory-safe languages, which don't rely so much on machine-level defenses? I guess you're losing something if you load a C library into your Java program, because exploits in the C library can do more damage now. But at the same time, having the majority of your code in Java is probably a win for security?
The idea is to leverage heap spraying[0] in the pages to write shell code which can then be triggered from another vulnerability in the program. This shell code could live in some string in a chunk of javascript. Thus, this technique does not need to violate the memory safety of the JITTed code. This can be partially mitigated using constant blinding[1] but it isn't perfect.
SSL is only one type of security, and not a large one at that. It mostly only protects data that is in flight between SSL libraries on each end of the connection. Of course those SSL terminators become the target of attacks, and as of so far a big one comes out every once in a while. OpenSSL, for example, is generally considered a large piece of crap.
That said I do agree that pushes, especially from Google, have made HTTPS much more secure lately.
Considering the state of commercial operating systems in terms of respecting the rights of users and their privacy, both of which are security issues, our computer security is for the most part compromised and will be for the foreseeable future.
Until we build in security mitigation into the kernel and standard libraries of our operating systems, we will always have failure modes where minor errors in code can result in critical vulnerabilities and privilege escalation. I love what OpenBSD is doing with pledges[0] and hope to see this gain traction in other operating systems. Here is a good overview of Pledge[1] by Theo de Raadt. Unfortunately for Linux ecosystem, the Kernel does not include any standard libs for developers, so this type of security mitigation will take a long time to arrive. But for Unix based operating systems we should expect this much sooner.
Do you figure computer security has been deliberately broken by the various security services to protect us from the terrorists or to more easily spy on their own citizens.
22 comments
[ 4.4 ms ] story [ 57.2 ms ] thread(I'm actually an Economist subscriber, I just wasn't logged in.)
My how things have not changed since 1999.
http://news.bbc.co.uk/2/hi/503224.stm
Here you'll find the latest in information security.
For example, here are just the top entries at the emoment.
How I found a command injection vulnerability in my TV set while in bed (and how I exploited it using nc)
PS4 4.0x WebKit Exploit Writeup (github.com)
How to find 56 potential vulnerabilities in FreeBSD code in one evening
Detecting and recovering from brute-forced RDP attacks (xednaps.com)
CVE-2017-2416 Remote code execution triggered by malformed GIF in ImageIO framework (blog.flanker017.me)
It's a fascinating field and the number of exploits appearing everyday is truley scary.
It must be difficult to get better because new software comes out all the time, and old software stays around. So the attack surface grows. IoT really pushes that model hard. I know the firmware in my TV hasn't changed since I bought it, but the newer model of the same TV has different firmware.
If you read to the end of the article, it discusses recent DARPA projects that are addressing the tools and languages component. And most of this stuff is still in heavy development. Even assuming that we get it sorted out soon, it will still be years and years before most deployed software is built on these improved foundations.
So yes, things are starting to get better. But it will take a long time before we see the results.
It's a fairly big jump for me to see the low end vendors adopting high end techniques when they don't even use ancient best practice.
What we have achieved is that if you are willing to keep things simple and give up much of the modern world (e.g. JITs) you can build far more secure software than what was possible in the past. What we have done is extend the realm of the possible in both the direction of security and vulnerability (e.g. before TrustZone it wasn't possible to leverage TrustZone to exploit a kernel).
So each time the JIT (re)compiles the code, it can call mprotect on the target page to allow writes and disable execution. Then after it's done, it calls mprotect again to disable writes and allow execute.
1. Put shell code in a string in some js,
2. get browser to JIT js and thus write the string that contains the shell code to an execute page in memory,
3. exploit a vulnerability and point the instruction pointer to the location of the string which contains the shellcode.
Normally, i.e. outside of a JIT, this wouldn't work because the string would be saved to a non-executable page.
That makes sense. Thanks!
[0]: https://en.wikipedia.org/wiki/Heap_spraying [1]: https://www.internetsociety.org/doc/dachshund-digging-and-se...
That said I do agree that pushes, especially from Google, have made HTTPS much more secure lately.
[0]: http://man.openbsd.org/pledge, [1] https://www.youtube.com/watch?v=F_7S1eqKsFk