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

Microsoft: 70 percent of all security bugs are memory safety issues

zdnet.com

Post reply on HN
Print view View original

171–180 of 180 posts

Re: Microsoft: 70 percent of all security bugs are memory safety issues

#171

Post by nineteen999 »

pjmlp wrote: post #159
nineteen999 wrote: post #156

Earlier quoted context omitted.

So you are talking about "Office 365 Mobile" and/or "Office 365 Online". There is also "Office 365 Desktop" which is what I think you'll find most large corporations that have migrated from Office 2016 Desktop apps are using. https://www.howtogeek.com/334597/whats-the-difference-betwee... Office 365 Mobile/Online are much cut down, more comparable from Google Docs from the sounds of it, and hardly a 1:1 replacement f…

If you have any hard evidence that the majority of the Office Mobile/Online web apps are written in C++ I would like to see that, because I can't seem to find any. Thankyou.

I have not made that assertion at all, not even implicitly. Therefore there is nothing to prove.

You still have an explicit outstanding assertion that they are written in C# though, once we figured out which of the three versions you were actually talking about (ie: it's the versions that almost nobody uses) so let's see it.

Re: Microsoft: 70 percent of all security bugs are memory safety issues

#172

Post by pjmlp »

nineteen999 wrote: post #171
pjmlp wrote: post #159

Earlier quoted context omitted.

If you have any hard evidence that the majority of the Office Mobile/Online web apps are written in C++ I would like to see that, because I can't seem to find any. Thankyou.

I have not made that assertion at all, not even implicitly. Therefore there is nothing to prove. You still have an explicit outstanding assertion that they are written in C# though, once we figured out which of the three versions you were actually talking about (ie: it's the versions that almost nobody uses) so let's see it.

Quite the contrary, I explicitly mentioned "I was referrring to Office 365 on Azure, which happens to run on the browser in case you missed it.", but I guess you rather push this little number of your's, therefore there is nothing to prove.

Re: Microsoft: 70 percent of all security bugs are memory safety issues

#173

Post by nineteen999 »

pjmlp wrote: post #172
nineteen999 wrote: post #171

Earlier quoted context omitted.

I have not made that assertion at all, not even implicitly. Therefore there is nothing to prove. You still have an explicit outstanding assertion that they are written in C# though, once we figured out which of the three versions you were actually talking about (ie: it's the versions that almost nobody uses) so let's see it.

Quite the contrary, I explicitly mentioned "I was referrring to Office 365 on Azure, which happens to run on the browser in case you missed it." , but I guess you rather push this little number of your's, therefore there is nothing to prove.

First message:

> How do you think Office 365 works?

Second message:

> I was referrring to Office 365 on Azure

Everyone can see it, its there and black and white. Having received your clarification that you meant "mobile or online" edition, I asked you to provide evidence it's written in C# which is apparently your claim, which you still haven't done. I haven't asserted that it's still written in C or C++, it could be assembled with spit and paper clips for all I know.

So enlighten us, as per your claim, if you can. I'm genuinely interested.

Re: Microsoft: 70 percent of all security bugs are memory safety issues

#174

Post by [deleted] »

spricket wrote: post #122

I hope Rust comes of age in a few years. Java, Go, and C# are above 50% "native" speed in every benchmark I've run across, but the mantra continues to be "why would I pick something slower?". Rust is the answer everyone wants, even if they don't really need it. An aside, C# in .NET core is getting very close to native speed. It's passed Java in many benchmarks, mostly due to type reification and lack of boxed primiti…

[deleted]

Re: Microsoft: 70 percent of all security bugs are memory safety issues

#175

Post by naikrovek »

maxxxxx wrote: post #160
naikrovek wrote: post #157

Earlier quoted context omitted.

Well, UWP and WPF are close cousins, so it probably isn't as bad as one would think if they didn't know that. They're both XAML, though they are not quite the same. The main thing is that with WPF you can use the same Win32-type logic you've always been using. UWP is it's own API entirely. It's not all that different, but it is different. Things are organized better and APIs make more sense in UWP-land to me. So the…

The GUI would be the easy part but our applications have a lot of background logic. Going to UWP would be almost a complete rewrite without actually improving anything. From what I have seen so far UWP is just different but not really better than WPF.

Can't argue with any of that.

Presumably, at some point in the future UWP support will extend beyond WPF's support window, and right now they are both supported, so it would be silly to switch solely for the sake of making IoT Core a viable deployment platform for you.

Re: Microsoft: 70 percent of all security bugs are memory safety issues

#176

Post by pjmlp »

m0zg wrote: post #134
Someone1234 wrote: post #110

Earlier quoted context omitted.

> Midori, as cool as it was, was Microsoft's "no output division" Considering you have absolutely no proof of that it seems rather disrespectful to act like that's a fact rather than your supposition.

It always cracks me up when people demand "proof" of something like this. I mean, I know some of the people from there from way back, and the project was eventually canceled, so there literally was "no output". And they had pretty much complete carte blanche on everything and could bikeshed over the most inane and inconsequential things for months on end. It was a fun "job" while it lasted, though.

Surely there was output.

Async/await, TPL, Span, blittable structs, safe stackalloc, .NET Native, and a couple of other minor features come from M# (System C#) usage.

Re: Microsoft: 70 percent of all security bugs are memory safety issues

#177

Post by afiori »

mike_hearn wrote: post #148
millstone wrote: post #132

Earlier quoted context omitted.

Agreed on principle but not sure it can be bootstrapped. What would you write, say, v8 in? Rust doesn't have any provisions against type confusion, JIT bugs, etc, and v8 seems way too complex for a formal verification.

That's extremely easy to answer. The answer is you'd write an interpreter for JavaScript in Java, use a partial evaluation framework also written in Java to convert it to a JIT compiler, and then run it on a multi-purpose optimising polyglot virtual machine that's also written in Java. Such a thing would be fully bootstrapped and fully managed. And usefully, it exists already. That's what happens if you run JavaScrip…

If I understand what you are describing this is how PyPy works.

Re: Microsoft: 70 percent of all security bugs are memory safety issues

#178

Post by rurban »

sanxiyn wrote: post #107
pcwalton wrote: post #80

Earlier quoted context omitted.

If we all wrote in languages as memory-safe as Java, almost all these security bugs would go away. Is Rust guaranteed to be 100% memory-safe? No, there could always be bugs in the compiler and/or unsafe code. (Aside: it annoys me how people consider the presence of an unsafe keyword inherently less trustworthy than a non-verified compiler/runtime system, when there is really little difference between them.) Is it a h…

Full agreement, but I think unsafe-phobia is mostly about user-extensible nature of it. unsafe in standard library is okay, because as you said it's no more dangerous than doing it in runtime. unsafe in "your" library is not okay, because I don't trust you to modify runtime either.

unsafe memory and unsafe types are not okay if you widely claim to be memory safe. Thousands of people actually believe these lies, and companies do makes decisions on these claims. It's much more memory unsafe than Java in fact. Java recently removed the unsafe tricks, whilst rust was once safe and went more and more unsafe since.

Re: Microsoft: 70 percent of all security bugs are memory safety issues

#179

Post by sempron64 »

sanxiyn wrote: post #99
pron wrote: post #69

Earlier quoted context omitted.

That's not an endgame if the resources required to block an attack are significantly greater than those required to make one. Moreover, verification is done with respect to specific properties that ensure no attacks of a particular kind . The more kinds of attacks you need to defend yourself from, the harder you need to work (and you will miss some). Not saying we're not making steps in the right direction, but no on…

> Moreover, verification is done with respect to specific properties that ensure no attacks of a particular kind. No. seL4 proved functional correctness. It eliminates all attacks, not just particular kinds. Functional correctness means implementation matches specification. As a corollary, seL4 has no buffer overflows. Proof: Assume seL4 has a buffer overflow. Exploit it to run arbitrary code. Arbitrary code executio…

From the assumptions page: http://sel4.systems/Info/FAQ/proof.pml

```

Hardware: we assume the hardware works correctly. In practice, this means the hardware is assumed not to be tampered with, and working according to specification. It also means, it must be run within its operating conditions.

Information side-channels: this assumption applies to the confidentiality proof only and is not present for functional correctness or integrity. The assumption is that the binary-level model of the hardware captures all relevant information channels. We know this not to be the case. This is not a problem for the validity of the confidentiality proof, but means that its conclusion (that secrets do not leak) holds only for the channels visible in the model. This is a standard situation in information flow proofs: they can never be absolute. As mentioned above, in practice the proof covers all in-kernel storage channels but does not cover timing channels

```

Rowhammer and Spectre exploits hardware not working to spec.

These sorts of attacks using heretofore "unreasonable" exploitation of side-channel and hardware vulnerabilities are exactly what worries me. We have no solutions for these classes of attacks. Complex high-speed systems are still inherently unsolvably vulnerable, it seems.

Re: Microsoft: 70 percent of all security bugs are memory safety issues

#180

Post by sempron64 »

monocasa wrote: post #56
chillacy wrote: post #54

Earlier quoted context omitted.

But does formal verification even help when you're up against side channel attacks on the hardware? Like the branch predictor or DRAM memory access timing.

With a model of the full system, quite possibly. That's one of the things that makes me so excited for RISC-V.

I don't know of any technique to model or avoid timing attacks that wouldn't drastically slow down execution to the point of being impractical.
Post reply on HN