9 ms·
The Rule of 2
- est31 7y ago> 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. > Unsafe implementation languages are languages that lack memory safety, including at least C, C++, and assembly language. Memory-safe languages include Go, Rust, Python, Java, JavaScript, Kotlin, and Swift Very nice. At the end of the process, Google might adopt Rust in Chromium. As much as I use and love Firefox, it's only realist to say that Chrome has higher chances of being around in 10 years. I wonder why the list doesn't include their wuffs language.
- ufmace 7y agoWell it isn't meant to be an exhaustive list of languages that are memory-safe. I could complain that Ruby isn't in there, but it isn't very popular in the Google world right now. I think we all get the idea though.
- tyingq 7y ago"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.
- amoitnga 7y agoIs Ruby memory-safe?
- tyingq 7y agoNo (direct) pointers or malloc, and garbage collected, so yeah.
- jillesvangurp 7y agoLots of native extensions though. So indirectly plenty of possibility for abuse. Some implementations are better at this than others.
- pjmlp 7y agoSelective view based on in house languages.
- jchw 7y agoI 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.)
- lisper 7y agoAnd the original memory-safe language: Lisp.
- rectang 7y agoNo-thank-you to the gratuitous Firefox FUD.
- est31 7y agohttps://gs.statcounter.com/browser-market-share/desktop/worldwide/#monthly-200907-201907 https://gs.statcounter.com/browser-market-share/desktop/worl... https://data.firefox.com/dashboard/user-activity https://data.firefox.com/dashboard/user-activity If you check where Firefox was 10 years ago to where it's now you can see the trend. It still continues. In the last year, Firefox lost more than 10% of its market share. A component of this is probably Firefox not being able to capture growth of the entire market, but the trend also holds for the absolute number of users: 890 million YAUs in Jul 2018 vs 809 YAUs in Jul 2019. In the long term view, Firefox is dying.
- deleted 7y ago[deleted]
- eikenberry 7y agoNeither of those charts go back far enough because if they did you'd see this has all happened before, and even worse at one point. When IE was taking over the world FF fell to <5% of the market, yet it survived. It's not dead until its dead and with Chrome killing off ad-blockers I bet we'll see some reversal of the current trends when that ships.
- dtech 7y agoWhen IE had taken over the world (~2002) Firefox did not exist yet, unless you include Netscape or Mozilla Suite
- rectang 7y agoSo what? Is it your mission to threadjack every story and turn it into a conversation about Firefox market share? When you observe someone using Firefox do you interject, "You know that Firefox is dying, right?" When you participate in meetings, do you open with "I'd like to state for the record that Firefox is doomed, doomed I say"? At the coffee shop in the morning, do you order "Grande Mocha, hold the Firefox because all hope is lost"?
- oconnor663 7y ago> 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, plausibly-safe parser. It's interesting to get a sense of how deeply unrealistic they think it is, to write a safe parser for a typical data format in an unsafe language.
- pjmlp 7y agoBecause 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.
- deleted 7y ago[deleted]
- mxcrossb 7y agoThe PSP was hacked by pirates when a bug was discovered in its image app (I think for tiff files). It makes me wonder if security should be baked in to a data format.
- zetafunction 7y ago
- johnday 7y agoTwo 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?
- muterad_murilax 7y ago"Always two there are; no more, no less. A master and an apprentice."
- skybrian 7y agoIt's practical advice for Chrome developers wanting to get a patch accepted. Deciding to rewrite the high-privilege parts of Chrome in Rust (say) is too big a project to be in scope.
- zetafunction 7y ago1. The only option for avoiding an unsafe implementation language is currently Java, which is limited to Android. 2. Avoiding high privilege often means going out of process, which is challenging on resource-constrained devices.
- emilfihlman 7y agoImage is broken.
- jandrese 7y agoIt's hosted off of a private google drive.
- tyingq 7y ago"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 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 information (see perllocale), results of certain system calls (readdir(), readlink(), the variable of shmread(), the messages returned by msgrcv(), the password, gcos and shell fields returned by the getpwxxx() calls), and all file input are marked as "tainted"." Unrelated rant: Sometime recently mobile chrome omits any part of a url after a # when you copy/share the url. Grrr.
- realharo 7y agoI'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 portion of most language's standard libraries to enforce it in practice (because they already return regular strings for inputs).
- 13of40 7y agoHow about implementing it as an access modifier like "trusted" and enforce that only values from other trusted members can be assigned to a trusted member?
- staticassertion 7y agoI think this is just refinement types. You wouldn't so much ban the stdlib as need to wrap it.
- deleted 7y ago[deleted]
- aidos 7y ago
- Vogtinator 7y ago"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.
- pjmlp 7y agoMorris Worm. About 70% of CVE reported exploits are due to memory corruption. Living with the remaining 30% would already be a huge security improvement.
- Vogtinator 7y agoThe 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 something which makes it much harder introducing memory safety issues, but it's not nearly as big as many here on HN think.
- pjmlp 7y agoYet we keep having those yearly 70%, go figure.
- missblit 7y agoDidn't Heartbleed rely on reading uninitialized data? I'd assume memory safety includes preventing code from reading uninitialized data.
- staticassertion 7y agoYes, and correct.
- deleted 7y ago[deleted]
- kazinator 7y agoHow about rule of 3: - 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.
- abalaji 7y agoDoes anyone have a working link to the diagram at the top? It seems to be a Google Drawing that requires permission to view/