Spying on HTTPS
> While most users probably would have no idea what to make of this, I happened to know what it means– Chrome is warning me that the system configuration has instructed it to leak the secret keys it uses to encrypt and decrypt HTTPS traffic to a stream on the local computer.
High-performance input handling on the web
> There is a class of UI performance problems that arise from the following situation: An input event is firing faster than the browser can paint frames.
> In a previous post, I discussed Lodash’s debounce and throttle functions, which I find very useful for these kinds of situations. Recently however, I found a pattern I like even better, so I want to discuss that here.
Follow up: https://nolanlawson.com/2019/08/14/browsers-input-events-and-frame-throttling/
Google and Mozilla are failing to support browser extension developers
> It is a regular occurrence to hear about open source developers selling their browser extensions, only for their users to be exploited later on by the new owners.
One of the reasons I’m wary of extensions. Least audited and least controlled code delivery mechanism for many systems.
Adblocking: How About Nah?
> The rise and rise of ad-blockers (and ad-blocker-blocker-blockers) is without parallel: 26% of Internet users are now blocking ads, and the figure is rising. It’s been called the biggest boycott in human history.
> Adversarial interoperability occurs when someone figures out how to plug a new product or service into an existing product or service, against the wishes of the company behind that existing product or service.
Plus a history of ads on the web.
Getting Into Browser Exploitation
Last post in series, toc at the top.
> 0x00: New Series: Getting Into Browser Exploitation
> 0x02: The Butterfly of JSObject
> 0x04: WebKit RegExp Exploit addrof() walk-through
> 0x05: The fakeobj() Primitive: Turning an Address Leak into a Memory Corruption
> 0x07: Preparing for Stage 2 of a WebKit exploit
> 0x08: Arbitrary Read and Write in WebKit Exploit
The Mutable Web
> This is my question: why do we put up with websites that we don’t like looking at? I think most people would answer that question with another question: What choice do we have?
DataSpii: The catastrophic data leak via browser extensions
> Our investigation uncovered an online service selling the collected browsing activity data to its subscription members in near real-time. In this report, we delineate the sensitive data source types relevant to the security of individuals and businesses across the globe. We observed two extensions employing dilatory tactics — an effective maneuver for eluding detection — to collect the data. We identified the collection of sensitive data from the internal network environments of Fortune 500 companies.
Browers can't feasibly stop web pages from talking to private (local) IP addresses
> This is a tempting and natural viewpoint, but unfortunately this can’t be done in practice without breaking things. To understand this, I’ll outline a series of approaches and then explain why they fail or cause problems.
Zoom Zero Day: 4+ Million Webcams & maybe an RCE? Just get them to visit your website!
> On Mac, if you have ever installed Zoom, there is a web server on your local machine running on port 19421. You can confirm this server is present by running lsof -i :19421 in your terminal.
> I also found that, instead of making a regular AJAX request, this page instead loads an image from the Zoom web server that is locally running. The different dimensions of the image dictate the error/status code of the server. You can see that case-switch logic here.
> One question I asked is, why is this web server returning this data encoded in the dimensions of an image file? The reason is, it’s done to bypass Cross-Origin Resource Sharing (CORS). For very intentional reasons, the browser explicitly ignores any CORS policy for servers running on localhost.
And it only gets better.
Scrolling the main document is better for performance, accessibility, and usability
> This subscroller fix may be obvious to more experienced web devs, but to me it was a bit surprising. From a design standpoint, the two options seemed roughly equivalent, and it didn’t occur to me that one or the other would have such a big impact, especially on mobile browsers. Given the difference in performance, accessibility, and usability though, I’ll definitely think harder in the future about exactly which element I want to be the scrollable one.
Provoking browser quirks with behavioural fuzzing
> The first bug I want to talk about is how to close a HTML comment in a different way. If you read the HTML specification you’ll know that you can close a comment with --> or --!> but what about another way? This is a great question to start off fuzzing with. You just then need to generate some code that answers that question.
Games and Graphics in Popup URL bars
> When I animated the URL bar with emojis I mentioned that I’d like to take it to the next level by putting a teeny game inside the URL bar. Well... Some really fine folks beat me to that. But I still wanted to give it a go ! I just needed to come up with something FRESH to work into it...
> So while thinking about how I could expand beyond the 1-dimensional movement of a URL bar, it came to me... Popups ! Yes, the bane of early 2000s internet will help me in 2019 achieve my emoji-url-bar-gaming dreams. By just opening a series of popups and overlapping them in a column we create a 2-dimensional display of sorts:
SensorID Sensor Calibration Fingerprinting for Smartphones
> We have developed a new type of fingerprinting attack, the calibration fingerprinting attack. Our attack uses data gathered from the accelerometer, gyroscope and magnetometer sensors found in smartphones to construct a globally unique fingerprint.
> Font and date adjustments to accommodate the new Reiwa era in Japan
Stealing Downloads from Slack Users
> The vulnerability could have allowed a remote attacker to submit a masqueraded link in a slack channel, that “if clicked” by a victim, would silently change the download location setting of the slack client to an attacker owned SMB share. This could have allowed all future downloaded documents by the victim to end up being uploaded to an attacker owned file server until the setting is manually changed back by the victim.
Technical Details on the Recent Firefox Add-on Outage
> Recently, Firefox had an incident in which most add-ons stopped working. This was due to an error on our end: we let one of the certificates used to sign add-ons expire which had the effect of disabling the vast majority of add-ons. Now that we’ve fixed the problem for most users and most people’s add-ons are restored, I wanted to walk through the details of what happened, why, and how we repaired it.
Improving privacy and security on the web
Title is vague. Punch line:
> This change also has a significant security benefit for users, protecting cookies from cross-site injection and data disclosure attacks like Spectre and CSRF by default. We also announced our plan to eventually limit cross-site cookies to HTTPS connections, providing additional important privacy protections for our users.
A Conspiracy To Kill IE6
> The bittersweet consequence of YouTube’s incredible growth is that so many stories will be lost underneath all of the layers of new paint. This is why I wanted to tell the story of how, ten years ago, a small team of web developers conspired to kill IE6 from inside YouTube and got away with it.
If you can get somebody to copy your decision fast enough, you can just claim you were copying them...
> Shortly thereafter, the Google Docs engineers whipped up their own IE6 banner and pushed it into production, presumably under the mistaken assumption that we had done our diligence and had received all of the necessary approvals. The first time many Googlers heard chatter about IE6 banners was from email threads where other teams had begun asking if they could deprecate IE6 like Google Docs had. Luck would have it that this had included many of our managers. Amazingly, we had somehow bypassed detection as the originators of the IE6 banner inside of Google.
A year with Spectre: a V8 perspective
> In theory, it would be sufficient to defeat either of the two components of an attack. Since we do not know of any way to defeat any of the parts perfectly, we designed and deployed mitigations that greatly reduce the amount of information that is leaked into CPU caches and mitigations that make it hard to recover the hidden state.
> Fortunately or unfortunately, our offensive research advanced much faster than our defensive research, and we quickly discovered that software mitigation of all possible leaks due to Spectre was infeasible. This was due to a variety of reasons. First, the engineering effort diverted to combating Spectre was disproportionate to its threat level. In V8 we face many other security threats that are much worse, from direct out-of-bound reads due to regular bugs (faster and more direct than Spectre), out-of-bound writes (impossible with Spectre, and worse) and potential remote code execution (impossible with Spectre and much, much worse). Second, the increasingly complicated mitigations that we designed and implemented carried significant complexity, which is technical debt and might actually increase the attack surface, and performance overheads. Third, testing and maintaining mitigations for microarchitectural leaks is even trickier than designing gadgets themselves, since it’s hard to be sure the mitigations continue working as designed. At least once, important mitigations were effectively undone by later compiler optimizations. Fourth, we found that effective mitigation of some variants of Spectre, particularly variant 4, to be simply infeasible in software, even after a heroic effort by our partners at Apple to combat the problem in their JIT compiler.
Attacking Clientside JIT Compilers
> Our research focused on 3 front end compilers and back end JIT engines for which little, or no public security research exists. We explore the potential security impacts of using JIT engines in applications such as web browsers and language runtimes and describe the tools we developed for security researchers to build on our JIT research. We also discuss a case study of a security vulnerability we found in the Firefox SpiderMonkey front end and discuss ways the back end JaegerMonkey JIT can be used to exploit the vulnerability. Finally, we will conclude with discussion on possible techniques for hardening JIT implementations that apply to both browser and language runtime JIT engines.
Per the author, “Despite being written by a much younger, and dumber, me, this paper on JIT engines has aged well.”