31–40 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?
- untrustworthy inputs
- privilege
- unsafe language
- big, ball-of-mud codebase
We can do the first three, if the thing is small and simple.
Pretty much every OS kernel out there in wide deployment has all four of the above, though.
"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 probably sharing the canonical link. That's the "correct" behaviour as defined by browsers. Definitely not ideal in your example, though.
"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…
Though I don't have experience with it, maybe one reason it isn't used is because of false positives?
For efficiency reasons, Perl takes a conservative view of whether data is tainted. If an expression contains tainted data, any subexpression may be considered tainted, even if the value of the subexpression is not itself affected by the tainted data.
Has anyone used this? Is the runtime overhead always there, or only when you turn the taint mode on? It seems like it would have to occupy some extra space in the string objects all the time? (Although I guess if it's literally a single bit, it can come for "free" because of padding)
-----
FWIW here are some references on static taint analysis:
https://cacm.acm.org/magazines/2019/8/238344-scaling-static-...
cites https://www.usenix.org/legacy/event/sec06/tech/full_papers/x...
Earlier quoted context omitted.
Selective view based on in house languages.
I work at Google and as far as I know Rust is not really “in house” at Google, at least not any more than C#. Both languages exist in some form, Google does have some plugins for Unity and I believe Fuchsia has some Rust code. It is indeed unclear what criteria was used to select languages, though it’s really not very relevant to the primary point anyway. (Legal line noise: my opinions are not those of my employer.)
> 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…
"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.
"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…
https://nim-lang.org/docs/manual_experimental.html#taint-mod...
"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…
I'm not aware of a similar feature built into other languages, but most of it could be easily achieved with almost any type system. Just have two separate types, e.g. UnsafeString and regular String, and some kind of `convert` function that takes a validation function as an argument. You'd get compile-time checking that way. People don't tend to use such things in practice though, and you would also have to ban a por…
"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…
I'm not aware of a similar feature built into other languages, but most of it could be easily achieved with almost any type system. Just have two separate types, e.g. UnsafeString and regular String, and some kind of `convert` function that takes a validation function as an argument. You'd get compile-time checking that way. People don't tend to use such things in practice though, and you would also have to ban a por…
"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.