Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Rule of 2

chromium.googlesource.com

Post reply on HN
Print view View original

11–20 of 59 posts

Re: The Rule of 2

#11

Post by amoitnga »

tyingq wrote: post #6
est31 wrote: post #2

> 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.

Is Ruby memory-safe?

Re: The Rule of 2

#12

Post by tyingq »

amoitnga wrote: post #11
tyingq wrote: post #6

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.

Is Ruby memory-safe?

No (direct) pointers or malloc, and garbage collected, so yeah.

Re: The Rule of 2

#13

Post by Vogtinator »

"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.

Re: The Rule of 2

#15

Post by pjmlp »

tyingq wrote: post #6
est31 wrote: post #2

> 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.

Selective view based on in house languages.

Re: The Rule of 2

#16

Post by pjmlp »

Vogtinator wrote: post #13

"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.

Re: The Rule of 2

#17

Post by rectang »

est31 wrote: post #2

> 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…

No-thank-you to the gratuitous Firefox FUD.

Re: The Rule of 2

#18

Post by realharo »

tyingq wrote: post #9

"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 portion of most language's standard libraries to enforce it in practice (because they already return regular strings for inputs).

Re: The Rule of 2

#19

Post by steveklabnik »

tyingq wrote: post #9

"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.

Re: The Rule of 2

#20

Post by est31 »

rectang wrote: post #17
est31 wrote: post #2

> 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…

No-thank-you to the gratuitous Firefox FUD.

https://gs.statcounter.com/browser-market-share/desktop/worl...

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.

Post reply on HN