[Webkit-unassigned] [Bug 196533] [META] Undefined behavior bugs

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=196533

Michael Catanzaro <mcatanzaro at igalia.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mcatanzaro at igalia.com

--- Comment #17 from Michael Catanzaro <mcatanzaro at igalia.com> ---
(In reply to Yusuke Suzuki from comment #16)
> Filed an issue enabling -fwrapv / d2UndefIntOverflow. I'll look into it at
> weekend as my hobby project.
> https://bugs.webkit.org/show_bug.cgi?id=196829
> 
> It seems that JF attempted to make signed-overflow non-UB, but the sad thing
> is that it is rejected by WG21 :(

Thanks Yusuke. But does -fwrapv cause ubsan to not complaining about signed overflow? I would guess not?

(In reply to Brent Fulgham from comment #8)
> I think that Sony's goals here are really well aligned with Apple's. WebKit
> is the primary source of system exploits on our systems, too, so anything we
> can do to deny attackers an avenue for exploit should be taken.
> 
> I support the idea of getting WebKit to be UBSAN clean, just like we want to
> be ASAN clean, Guard Malloc clean, etc. We should clean all the SANs!
> 
> Currently we are prioritizing things with probably paths to exploit, but I
> am in favor of making code changes to silence ASAN/TSAN/UBSAN warnings if it
> reduces noise so we can identify real problems or new regressions.

Just want to +1 Brent's comment here. Experience shows that WebKit is the easiest engine for Project Zero to exploit right now, by a lot, using a *publicly-available fuzzer* [1] that we just never bothered setting up infrastructure to run. We shouldn't be relying on security researchers to find vulnerabilities for us that we could easily find ourselves using the same tools. So it's great that Sony wants to help set up some security CI infrastructure. WebKit should be running as many static and dynamic analysis bots as possible. Right now, without bots, we are at a security disadvantage.

Then, once we have bots, we can see how much effort will be required to fix the issues found by the bots, including false positives. It might be annoying to fix or suppress false positive warnings indicated by a tool that you don't personally use -- I've never run WebKit under ubsan myself -- but these tools are so valuable for proactively finding security issues that it makes sense for WebKit to change to placate them.

Besides GuardMalloc and the LLVM sanitizers, we should also pay more attention to the Coverity scan results Red Hat provides us with (bug #104114) and the fuzzinator results (bug #116980) provided by Renata. We should also consider which publicly-available fuzzers we could be running, starting with Domato.

[1] https://googleprojectzero.blogspot.com/2018/10/365-days-later-finding-and-exploiting.html

(In reply to Don Olmstead from comment #4)
> In the long term we'd like to spin up bots running the different sanitizers
> to continuously look for issues. An issue there is that I don't know that we
> could lock down the logs to a bot if it were attached to build.webkit.org.
> I've talked a bit about this with Brent.

I think static and dynamic analysis CI should be a priority goal for the WebKit project right now due to its potential to reduce security issues in WebKit. The main questions are to what extent such bots can integrated into WebKit infrastructure, whether their results should be public, and which contributors should have access to them if they're not.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20190412/08562923/attachment-0001.html>