= Security Issues in WebKit =

//Brent Fulgham, Apple//

Bugs come in a variety of forms
- Bugs that allow arbitrary code execution
- exposing private customer data
- spoof content to fool the user

Security bugs come with deadlines
- usually 90 days from notification

Security bugs are closely watched
- Big industry, and reporters want to get their credit
- reputations are made and broken on the catalogue of CVE numbers they have
- More scrutiny than other bugs

Fixing security bugs may hurt your friends
- checking in a fix or shipping may 0-day other ports

Our Problem
- We’re an open source project
- how do we fix without advertising the problem to attackers?

Our Guidelines
- Put the bug in the Security component
	- Only visible to the originator, Security team, people CC’d on the bug
	- Opened up to everyone one year after WebKit ships the fix

Security Component Problems
- Check-ins attached to “Invisible” security bugs are a red flag
- EWS and commit-queue do not run on Security bugs :-(
	
Choose Wording Carefully
- arbitrary code execution, buffer overflow, buffer overrun, buffer underrun, CVE, dangling, pointer, double free, fuzzer, fuzzing, fuzz test, invalid, cast, malicious, memory corruption, security bug, security flaw, use after free, UXSS, vulnerability, spoofing, ZDI
- Don’t use these words
- Ultimately how do we shorten the time from the security bug knowledge to a fix running on user’s devices?

Test Case Hygene
- Avoid using “exploit-y” test cases
- often the underlying cause of a security bug can be tested with a benign layout test
	
Communication is Key
- Anyone shipping WebKit should be represented in the WebKit Security Team
- Several flavors: one is to be a vendor contact that can get notified
- Ideally WebKit ports should coordinate releases
	- If Apple ships an OS update, GTK or Sony could ship updates as well