[Webkit-unassigned] [Bug 107699] Add SECURITY_ASSERT

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Jan 23 23:12:17 PST 2013


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





--- Comment #20 from Abhishek Arya <inferno at chromium.org>  2013-01-23 23:14:10 PST ---
On Wed, Jan 23, 2013 at 10:59 PM, Simon Fraser <simon.fraser at apple.com> wrote:
It seems weird to add this new kind of assertion under the cover of a security bug, for two reasons. First, how are WebKit developers supposed to know when to use it? Second, it's just adding  release-build assertion that (I'm guessing) you enable for fuzzing. That doesn't seem to be exposing new vulnerabilities.

My mistake for filing it as a security bug, i just made it public. However, I did leave out a comment in the code explaining the purpose of this ASSERT. We cannot enable all asserts on our fuzzing cluster since only few asserts are known to cause security vulnerabilities. These asserts added in the two patches are known to cause bad casts [static_cast problems], out of bounds reads[vector.h ones], containernode document confusion[use after frees]. The places we are adding them are sure-shot security bugs, like bad cast due to wrong static_cast usage, out of bounds access in vector and list will grow with time. In normal builds, it will work as regular asserts. This assert will also help a dev hitting it to know that they should file a security bug when they encounter such issues (also in the comment) [seeing the assert name and read the description in assertions.h]. Regarding how webkit developers should add it is still hard and not encouraged in the first phase. We want security group members who know about these security problems should add it for now.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.


More information about the webkit-unassigned mailing list