21–30 of 59 posts
Two actually seems like a lot here. Why would you angle for two and not one? It seems like the latter two (unsafe implementation language and high privilege) are both within the purview of developers. Is it just a case of resource management?
"unsafe implementation language" is a pretty moot point. Looking at all the trivial exploits against web applications which are basically never written in memory-unsafe languages (Ruby, Python, PHP, ...) shows that it doesn't really matter much. While having the same implementation in a memory unsafe language would be slightly less safe, it's very unlikely that a heap corruption could be exploited remotely.
Morris Worm. About 70% of CVE reported exploits are due to memory corruption. Living with the remaining 30% would already be a huge security improvement.
Memory corruption is much harder (and in most cases realistically not at all) to exploit beyond a DoS, and that's what you would get with "safe" languages such as Rust or Python as well.
Heartbleed, Shellshock, Dirty COW etc. would all happen exactly the same way in different programming languages.
Yes, there is clearly a benefit in using something which makes it much harder introducing memory safety issues, but it's not nearly as big as many here on HN think.
> The Rule Of 2 is: Pick no more than 2 of > * untrustworthy inputs; > * unsafe implementation language; and > * high privilege. > Security engineers in general, very much including Chrome Security Team, would like to advance the state of engineering to where memory safety issues are much more rare. Then, we could focus more attention on the application-semantic vulnerabilities. That would be a big improvement. > Uns…
> But if you transform the image into a format that doesn‘t have PNG’s complexity (in a low-privilege process, of course), the malicious nature of the PNG ‘should’ be eliminated and then safe for parsing at a higher privilege level. Even if the attacker manages to compromise the low-privilege process with a malicious PNG, the high-privilege process will only parse the compromised process' output with a simple, plausi…
Because as of 2019 the same errors as in early 1980's keep being repeated, regardless how many tools have been developed to tame C and it's derivatives. It is so unrealistic that Android is following up Solaris footsteps. Google has announced that ARM memory tagging extensions will be required in future Android versions.
Earlier quoted context omitted.
Morris Worm. About 70% of CVE reported exploits are due to memory corruption. Living with the remaining 30% would already be a huge security improvement.
The Morris Worm happened back when security was not really a big concern. Memory corruption is much harder (and in most cases realistically not at all) to exploit beyond a DoS, and that's what you would get with "safe" languages such as Rust or Python as well. Heartbleed, Shellshock, Dirty COW etc. would all happen exactly the same way in different programming languages. Yes, there is clearly a benefit in using somet…
Earlier quoted context omitted.
Because as of 2019 the same errors as in early 1980's keep being repeated, regardless how many tools have been developed to tame C and it's derivatives. It is so unrealistic that Android is following up Solaris footsteps. Google has announced that ARM memory tagging extensions will be required in future Android versions.
When is Google going to require monthly security patch delivery?
According to an interview they gave to Are in 2017 about changing Play Store contract.
And the new Project announced at IO to require support for GSI images.
Earlier quoted context omitted.
Morris Worm. About 70% of CVE reported exploits are due to memory corruption. Living with the remaining 30% would already be a huge security improvement.
The Morris Worm happened back when security was not really a big concern. Memory corruption is much harder (and in most cases realistically not at all) to exploit beyond a DoS, and that's what you would get with "safe" languages such as Rust or Python as well. Heartbleed, Shellshock, Dirty COW etc. would all happen exactly the same way in different programming languages. Yes, there is clearly a benefit in using somet…
Earlier quoted context omitted.
"Memory-safe languages include Go, Rust, Python, Java, JavaScript, Kotlin, and Swift" An interesting list. They left out C# and PHP if it's supposed to be the most popular languages.
Selective view based on in house languages.
(Legal line noise: my opinions are not those of my employer.)
"If you can be sure that the input comes from a trustworthy source" Perl's "taint" [1] capability is pretty interesting in this space. Do other languages have something similar? [1] https://perldoc.perl.org/perlsec.html#Taint-mode "You may not use data derived from outside your program to affect something else outside your program--at least, not by accident. All command line arguments, environment variables, locale i…
It’s in Ruby as well, inherited from Perl. It doesn’t get much use though.
[1] https://api.rubyonrails.org/classes/ActiveRecord/Base.html#c...
[2] http://www.jkfill.com/2012/03/10/preventing-mass-assignment-...
"If you can be sure that the input comes from a trustworthy source" Perl's "taint" [1] capability is pretty interesting in this space. Do other languages have something similar? [1] https://perldoc.perl.org/perlsec.html#Taint-mode "You may not use data derived from outside your program to affect something else outside your program--at least, not by accident. All command line arguments, environment variables, locale i…