Several months in the life of Project Zero – Part 1: The Chrome bug of suffering | Hacker News Reader

Several months in the life of Project Zero – Part 1: The Chrome bug of suffering

googleprojectzero.blogspot.com

140 pointsarchimag027 comments

> At this point, we were questioning our decision-making process more thoroughly, and immediately tried reproducing with the same version on a Linux build. I think you, the reader, can imagine how we felt when the issue also reproduced locally with an ASAN Linux build…

This was my very first thought when I read that it occurred on Android, so I know it had to be someone’s first thought working on this. Very unfortunate, but I’m pretty sure we’ve all been there, with a gut feeling we either ignored or outright doubted that could’ve potentially saved months at minimal risk.

> C-style programming in C++ is also a bad sign; the IOBuffer design pattern with separate storage of buffers and their sizes is inherently dangerous.

This the main take away. Even when writing C, just prefer safe libraries to default strings and arrays, when possible.

By the way, MSR is hiring for Checked C.

>By the way, MSR is hiring for Checked C

Only internships ATM according to their web page

Internships aren't done for free, so it is still a job.

While that is true, when one says "hiring", it generally refers to a somewhat "tenured" or "continued" position.

At least that's what I understood from your original comment.

Fair enough.

https://github.com/Microsoft/checkedc#we-are-hiring

> We have positions available for a Principal Software Engineer and Senior Software Engineer. We are looking for engineers who have production compiler development experience and who value shipping software.

There is no reason to spend time on any variant of C in the age of Rust.

Sure there is, as much as I dislike C, no one is going to port the existing UNIX and POSIX clones to something else.

And even then, many of those interfaces are based in C semantics anyway.

So anything that helps to reduce the amount of possible security exploits per line of C code is welcomed.

For new projects, sure. For existing projects, it's not trivial to convert them and anyone working on something significant is going to need time to do a migration during which additional new C code will almost certainly need to be written.

It can be semi-automated with the amazing c2rust[1] tool.

[1] https://github.com/immunant/c2rust

“semi-” is not a synonym for “easily done with production-ready results”. Until that changes, people are going to need to write new C code even if they're working to refactor their code into a better language.

Good point. We can do this in Go.

That state machine is scary. I wouldn't dare to write it without an async/await generator.

I don't really understand this level of memory manipulation and exploit construction very well right now. But I notice that the usual Rust advocates are big on boosting how the language restrictions and constructs block these sorts of things. Can anybody comment on how many of the steps they used could actually be prevented by using Rust for this module?

If I had to summarize it, it would be:

> C-style programming in C++ is also a bad sign; the IOBuffer design pattern with separate storage of buffers and their sizes is inherently dangerous.

Rust has "slices", which store a pointer and a length together, so they cannot get out of sync like this.

Google projekt zero website is the ONLY website which frequently get featured on HN that I cannot read on my iphone. Safari, Firefox or Edge are all rendering the page with horizontal scrollbars. I can use 2 finger zoom in and then a third finger to move the content around. At that point I cannot see the screen for my fingers and have problems holding my phone in my hands.

Do they have a bounty program for HTML where one can submit a fix? /s

This is not a new issue. Been like that for a long time

I'm on Android so I don't have any trouble, but keep in mind that all "browsers" on iOS are just Safari with a skin and a few features bolted onto it. Apple doesn't allow different browser engines on their platform because of various reasons.

Try the non-mobile version: https://googleprojectzero.blogspot.com/2020/02/several-month...

It seems to be using the default simple blogger theme so there's probably no point of contact for the website, it's Google after all. The best chance you have is to submit a bug report with Apple about Safari not rendering the page right.

Wow, I couldn't believe it. https://en.wikipedia.org/wiki/Firefox_for_iOS

I just read both parts without even noticing but you’re right it does. I guess you have a different device/screen size as the position and scale is correct for me. It’s a bug in blogspot itself so far as I can tell.

Maybe it's a potential vulnerability they have yet to exploit themselves... /sarcasm and also maybe not.

All web browsers in iOS run the same engine (Safari). So while Google should fix their layout, this is a very good example on why Apple should allow alternative web engines in their OS.

Devil's advocate: Having only 1 engine means that a website only needs to test once to make sure they support all iPhone+iPad browsers.

Write to the spec and forget about it.

You might think so but you would be wrong. For example, try making a link to add a calendar event from Safari vs. Chrome vs. Facebook in-app browser, etc.

I have the same issue, it's extremely annoying. I just use Reader mode.

UPDATE: This issues appears to have been fixed now and the page renders as it should. Everything is now fine. Assuming that is this thread that caused someone to to take a look at the UI. Thank you very much Google project Zero :)

Ps: The down votes on my original rant can stop now, I hope. Thx ;)

Reply on news.ycombinator.com