www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - WhatsApp BO critical security vulnerability

reply XavierAP <n3minis-git yahoo.es> writes:
https://www.wired.com/story/whatsapp-hack-phone-call-voip-buffer-overflow/amp

«a WhatsApp exploit that could inject malware onto targeted 
phones—and steal data from them—simply by calling them. The 
targets didn't need to pick up to be infected, and the calls 
often left no trace on the phone's log. ...

«While WhatsApp bases its end-to-end encryption on the Signal 
Protocol, its VoIP calling functionally likely also includes 
other proprietary code as well. Signal says that its service is 
not vulnerable to this calling attack.

«According to Facebook's security advisory, the WhatsApp 
vulnerability stemmed from an extremely common type of bug known 
as a buffer overflow.»
May 14
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, May 15, 2019 at 06:53:27AM +0000, XavierAP via Digitalmars-d wrote:
 https://www.wired.com/story/whatsapp-hack-phone-call-voip-buffer-overflow/amp
[...]
 According to Facebook's security advisory, the WhatsApp vulnerability
 stemmed from an extremely common type of bug known as a buffer
 overflow.
Given the frequency and severity of buffer overflow and other memory-related bugs, people need a serious wakeup call to migrate away from languages that do not enforce bounds checking... T -- Time flies like an arrow. Fruit flies like a banana.
May 15
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 15 May 2019 at 22:42:34 UTC, H. S. Teoh wrote:
 Given the frequency and severity of buffer overflow and other 
 memory-related bugs, people need a serious wakeup call to 
 migrate away from languages that do not enforce bounds 
 checking...
And this is why I *never* use dmd's -release or -boundscheck switches. Just not worth the risk of taking out those checks.
May 15
next sibling parent reply Exil <Exil gmall.com> writes:
On Wednesday, 15 May 2019 at 22:45:44 UTC, Adam D. Ruppe wrote:
 On Wednesday, 15 May 2019 at 22:42:34 UTC, H. S. Teoh wrote:
 Given the frequency and severity of buffer overflow and other 
 memory-related bugs, people need a serious wakeup call to 
 migrate away from languages that do not enforce bounds 
 checking...
And this is why I *never* use dmd's -release or -boundscheck switches. Just not worth the risk of taking out those checks.
Depends on what you are doing, I always have those switches turned on, it's not worth the performance hit. Wouldn't be surprised if it had something to do with data received over the network. I always see people write code with assumptions that the data will be valid. A good assumption would be that it can't be trusted.
May 15
next sibling parent "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 5/15/19 6:42 PM, H. S. Teoh wrote:
 Given the frequency and severity of buffer overflow and other
 memory-related bugs, people need a serious wakeup call to migrate away
 from languages that do not enforce bounds checking...
Yea, people definitely do. But they never will unless they're absolutely, 100% *forced* to. For example... On 5/15/19 9:19 PM, Exil wrote:
 On Wednesday, 15 May 2019 at 22:45:44 UTC, Adam D. Ruppe wrote:
 And this is why I *never* use dmd's -release or -boundscheck switches. 
 Just not worth the risk of taking out those checks.
Same here.
 Depends on what you are doing, I always have those switches turned on, 
 it's not worth the performance hit.
Premature optimization. Sh****t...we live in a world where even those people using the el-cheapo completely-free-with-any-data-plan phones are walking around with a supercomputer in their pocket so absurdly powerful it can run Quake 2, at a good framerate, probably in software-rendering mode too, *as JavaScript executed in a bloated web browser*! If anyone's software needs bounds checks disabled ACROSS THE ENTIRE CODEBASE (?!?!) to run acceptably, then they're clearly doing something ELSE, very, very, horribly wrong. And they seriously need to 1. learn about premature optimization, 2. learn how to freaking profile and optimize, and 3. learn how to isolate inner-loop hot-spots from the rest of code and limit the security-disaster-in-waiting compiler flags to just that code alone...and audit that code to ensure outside input never reaches it unwashed. (although, anything the langs/compilers could do to push this and make it all more convenient would certainly help) Honestly though, granted I like and respect Walter a lot, but I've always felt...all his [absolutely correct] preaching about memory safety and profiling is rendered automatically dead-on-arrival by the very fact that we have a flag conveniently named "-release" which, among other conveniently dangerous things, kills bounds checking (?!). Summary: Performance in 2019??? Pftt, please, it's not worth the *security* hit. What is this, 1977?
May 15
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/15/2019 6:19 PM, Exil wrote:
 Wouldn't be surprised if it had something to do with 
 data received over the network. I always see people write code with
assumptions 
 that the data will be valid. A good assumption would be that it can't be
trusted.
Using asserts and relying on array bounds checking to check the validity of incoming data is incorrect. Asserts and bounds checking are for detecting bugs in the program's logic. Scrubbing input data for correctness is normal program behavior, and should never be disabled.
May 16
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, May 16, 2019 at 09:17:45AM -0700, Walter Bright via Digitalmars-d wrote:
 On 5/15/2019 6:19 PM, Exil wrote:
 Wouldn't be surprised if it had something to do with data received
 over the network. I always see people write code with assumptions
 that the data will be valid. A good assumption would be that it
 can't be trusted.
Using asserts and relying on array bounds checking to check the validity of incoming data is incorrect. Asserts and bounds checking are for detecting bugs in the program's logic. Scrubbing input data for correctness is normal program behavior, and should never be disabled.
Yes, that's what Exil meant by "A good assumption would be that it can't be trusted". Far too often I've seen code that declares a static buffer of 1024 or so bytes, then proceed to read in lines from stdin without checking for line length -- the (totally unwarranted) assumption being that the user wouldn't type a line that long. That has led to so many buffer overflow bugs. It's just a security exploit waiting to happen. But people keep doing it because in C, bounds checking is troublesome, and many stdlib functions have APIs that don't even accept any bounds. These two plus natural human laziness equals buffer overflows and security exploits galore (too lazy to check bounds, too much work to write utility functions with safer APIs instead of just using the unsafe stdlib ones). What we need is a language with the right incentives: bounds checking is default and it takes effort to turn it off (should that ever become necessary), and the standard library should always have an API that take bounds. These two then put human laziness on the right side of the fence -- you're safe by default, and disincentivised to write unsafe APIs in place of the standard, safe ones. Vetting input is a harder problem, though. It takes work to verify input, no matter how you cut it. So the only incentives I can think of to prod people in the right direction is some kind of tainting scheme like in Perl, where it's an error to operate on data that isn't vetted. But even then, the incentives are still not quite right -- the tainting mechanism becomes an annoyance to be rid of, which encourages doing the absolute minimal work to get it to pass rather than putting in the effort to do it right. I don't have a good answer for this one. T -- EMACS = Extremely Massive And Cumbersome System
May 16
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Thursday, 16 May 2019 at 16:41:29 UTC, H. S. Teoh wrote:
 What we need is a language with the right incentives: bounds 
 checking is default and it takes effort to turn it off (should 
 that ever become necessary), and the standard library should 
 always have an API that take bounds.
We have that language, it is called D. The only problem is so many people say "use -release -boundscheck=off" to get an extra percentage point on artificial benchmarks without educating people as to what that REALLY means.
May 16
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, May 16, 2019 at 04:58:25PM +0000, Adam D. Ruppe via Digitalmars-d wrote:
 On Thursday, 16 May 2019 at 16:41:29 UTC, H. S. Teoh wrote:
 What we need is a language with the right incentives: bounds
 checking is default and it takes effort to turn it off (should that
 ever become necessary), and the standard library should always have
 an API that take bounds.
We have that language, it is called D.
I know. ;-) When arrays come with bounds by default, the API doesn't have to be uglified, and non-library code also benefits from default bounds checking. Win-win.
 The only problem is so many people say "use -release -boundscheck=off"
 to get an extra percentage point on artificial benchmarks without
 educating people as to what that REALLY means.
Yeah, good ole premature optimization. I sympathize, because I used to be like that. But after so many times of the profiler pointing to a bottleneck that was far, far away from where I imagined it would be, it finally dawned on me that *most* code actually doesn't even matter when it comes to performance. And the small bit of code that's the bottleneck usually is slowed down by something either completely non-obvious (rare), or by something really silly (more common) like a misplaced debug printf that eats up orders of magnitude more cycles than any bounds check ever will. Not to mention, with a proper optimizing compiler like ldc2 -O3, many inner-loop bounds checks (where it matters) would be optimized away anyway. And if it doesn't, it's usually just a small effort to rewrite the code so that it doesn't need a bounds check. Slapping -release -boundscheck=off across the board is just ... hamfisted, and usually misguided. T -- There are two ways to write error-free programs; only the third one works.
May 16
parent Yatheendra <3df4 gmail.ru> writes:
Would it much hurt performant bounds-checks-off code if Phobos 
ranges had an 'assert(0)' on out-of-bounds in their constructors? 
It would make unchecked array accesses via ranges safe.
Jun 22
prev sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Thursday, 16 May 2019 at 16:17:45 UTC, Walter Bright wrote:
 Using asserts and relying on array bounds checking to check the 
 validity of incoming data is incorrect.
A security bug is necessarily a bug in the program's logic. It should be checked separately, but it should ALSO be checked automatically. In almost all situations. ESPECIALLY in production. It is defense-in-depth.
May 16
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, May 16, 2019 at 01:19:41AM +0000, Exil via Digitalmars-d wrote:
 On Wednesday, 15 May 2019 at 22:45:44 UTC, Adam D. Ruppe wrote:
 On Wednesday, 15 May 2019 at 22:42:34 UTC, H. S. Teoh wrote:
 Given the frequency and severity of buffer overflow and other
 memory-related bugs, people need a serious wakeup call to migrate
 away from languages that do not enforce bounds checking...
[...]
 And this is why I *never* use dmd's -release or -boundscheck
 switches.  Just not worth the risk of taking out those checks.
Depends on what you are doing, I always have those switches turned on, it's not worth the performance hit.
[...] Are you using dmd or ldc? 'cos if you're concerned about performance, you should be using ldc -O3 instead of dmd. I regularly get 20-30% speedups just by compiling with ldc instead of dmd, sometimes as much as 40%. Compiling with -release -boundscheck on dmd just because of performance is straining out the gnat but swallowing the camel. And did you profile before using -release? Unless you're doing a lot of array manipulations inside inner loops, I doubt bounds checking are the source of your performance issues. If they are, your best bet is to put that code in its own module and compile only that module with -release -boundscheck. It's just not worth the security risk to disable bounds checking in non-bottleneck code. T -- Those who don't understand Unix are condemned to reinvent it, poorly.
May 16
prev sibling parent Mike Franklin <slavo5150 yahoo.com> writes:
On Wednesday, 15 May 2019 at 22:45:44 UTC, Adam D. Ruppe wrote:

 And this is why I *never* use dmd's -release or -boundscheck 
 switches. Just not worth the risk of taking out those checks.
Can we deprecate that for -release? With the -boundscheck flag, don't users already have everything they need to disable it if they need to? But even if we can't, if the DIP to make D safe-by-default is approved, a side benefit is that -release will enable -boundscheck=safeonly, and then users can utilize -release with more confidence. Mike
May 15