ddworken

While this POC may not reliably work on Safari, it is worth noting that from a defense perspective Safari is missing site-isolation (which Chrome, Edge, and soon Firefox all have). So if an attacker were to get this to work on Safari, the impact would be potentially much greater in terms of what could be stolen.

Yeah, Firefox doesn't have it yet but as I understand it, they're getting very close to shipping Project Fission.

It is worth noting that this POC was specifically targeted at Chromium based browsers. To quote the blog post, they also developed "a PoC which leaks data at 60B/s using timers with a precision of 1ms or worse". So Firefox's protection's are likely not sufficient to mitigate all Spectre attacks.

This only allows reading data from the current process. Chrome and Edge have something called site-isolation where every site has its own process. In principle, this means that a site can only read its own resources. The catch here is that there are a bunch of different ways a site can include potentially sensitive resources from other sites (e.g. via referencing them with an `img` tag). So sensitive endpoints need to opt-in to additional protections that ensure they do not end up in cross-site browser processes.

But no, this isn't game over for running untrusted JS. It just means that we need to assume that JS can access anything in the same process.

The big caveat to this is that an attacker can generally get a browser to include a cross-site resource in their process. For example, `<img src="https://sensitive.com/myprofilepic.png">` will cause the image to be loaded in the attacker's process where they can then potentially steal it. The article "Post-Spectre Web Development" goes into details on how sites can defend against this (and other vectors).

Chrome's design ensures that Spectre can only access resources that end up in an attacker controlled process. And this [1] post on "Post-Spectre Web Development" goes into detail about how a given website can ensure that its resources don't end up in an attacker controlled process. There are also a number of default protections against this like SameSite cookies and CORB that protect some resources by default.

[1]: https://w3c.github.io/webappsec-post-spectre-webdev/

As I understand it (though I don't work directly on Chrome), a key part of Chrome's threat model is that a compromised renderer process (where there is one renderer process per site) has limited security impact. So being safe against Spectre (which gives a read primitive in the renderer process) is just a subset of being safe against a compromised renderer process.

Yeah, I think it is a bit unfortunate that there doesn't seem to be any way of hiding this implementation detail from developers. In general though, Chrome is very thoughtfully designed so things mostly work as you'd hope. The core of the process model is that each site (e.g. `ycombinator.com` not `news.ycombinator.com`) gets its own process. This [0] has a great list of things they've considered when designing site-isolation. For example, Chrome's password manager does respect site isolation and is designed to operate across multiple processes[1].

[0]: https://chromium.googlesource.com/chromium/src/+/master/docs... [1]: https://chromium.googlesource.com/chromium/src/+/master/comp...

Chromium has site-isolation (with some caveats around phones with limited resources) so both Chrome and Edge have site-isolation. Firefox is getting very close with Project Fission [1] and I predict they'll ship it relatively soon. Currently Safari doesn't have site-isolation and AFAIK they have not publicly committed to anything in terms of getting there. They have done some work in this space (search around for Process Swap on Navigation (PSON)) but it isn't complete.

[1]: https://wiki.mozilla.org/Project_Fission

See this[1] paper for more information. I think from the browser POV it is more about admitting that it just isn't possible to reliably mitigate Spectre and instead focusing on what can be done at the browser level. And at the browser level, it is possible to ensure that sensitive resources don't end up in processes running attacker JS.

Of course this could be fixed at the CPU level, but realistically very few people want that since that would drastically slow down modern CPUs which rely on speculative execution.

[1]: https://arxiv.org/pdf/1902.05178.pdf

Disclosure: I work at Google and am involved in deploying some of these cross-origin resource restrictions internally.

Last year Chrome published a great paper on this[1]. The summary is that we no longer think it is possible to completely prevent speculative execution bugs. A big focus nowadays is on providing tools (mainly via HTTP headers) that allow a website to opt-in to a more strict security model where specific sensitive resources can't end up in a process that is running untrusted code. If you're curious, check out this[2] document which explains a bunch of these different mechanisms.

Disclosure: I work at Google and am involved in deploying some of these features internally.

[1]: https://arxiv.org/pdf/1902.05178.pdf [2]: https://w3c.github.io/webappsec-post-spectre-webdev/

Vault's SSH certificate signing support is definitely really great and is something I modeled this project after while developing. Though I see it as more of a building block as opposed to a complete solution. With this project you:

* Don't have to run Vault (for companies that don't already use Vault, setting it up is a significant commitment). * Get simple user/group management within Keybase. * Get a simple CLI tool, kssh, that can be used instead of ssh that automatically manages renewing certificates. With vault a user has to manually use curl to request a new certificate whenever their's expires. With kssh, you just run `kssh user@server` and it all automatically works.

It is also worth noting that the example you posted above does not handle multiple realms of servers where some people only have access to staging and not production. With our SSH CA, this is all included in the default setup.

Wow, very surprised to hear that. I definitely recommend taking Marten up on his offer and sending him an email (this behavior—of the CEO reaching out to hackers—is much more in line with my own experiences with them).

Good luck with everything!

Wow, I'm definitely really surprised to hear that just because it is in such stark contrast to my own experience. If you don't mind me asking, how long ago was this? From my own experience, they're continually improving (they just added the response efficiency stats last may) and are putting a ton of effort into growing the hacker community.

Just wanted to chime in and say that working with them as a hacker is also a great experience. They put a ton of emphasis on the community with publicly disclosed reports (https://hackerone.com/hacktivity/popular), statistics on response efficiency (e.g. https://hackerone.com/uber), and a great support/mediation team (https://support.hackerone.com/hc/en-us/articles/210782803-Ho...). In addition, they also have a really admirable stance on transparency and it seems like they always share as much information as they can (e.g. https://www.hackerone.com/blog/fair-and-transparent-hacker-i...).

I've personally learned a ton from working on bug bounties through HackerOne and am unbelievably excited to see them continue to grow.

Over on his website [0], Samy provides a link to the source:

https://github.com/samyk/poisontap

[0]: https://samy.pl/poisontap/

Yeah exactly. I certainly was in it for more than the money and would have happily worked on it even if there were no bounties.

While I do have a bit of experience with it, I still try to remain casual about it. Not by any means the only thing I do (Heading out hiking on the appalachian trail tomorrow!) so I try not to take it seriously. Thanks though!

Also if anyone has any questions, let me know!

Yup planning on going to college so not interested in any full time job offers (though I have received them...).

Well I did get to meet with the Secretary of Defense and get his personal challenge coin! And they did pay out bounties, I just wasn't the first to report the ones I sent in (despite sending most of them in on the first day).

It has now been fixed. The problem stemmed from allowing the `Javascript:` scheme for the home_page, download_url, and the url parameters in the setup.py.

Thanks for reposting that comment here (I posted it on /r/python). I'm now in contact with him and I'll update this once it has been fixed.

For anyone curious, you can easily host html, css, and javascript on KBFS without too much extra work. See dworken.keybase.pub/blog/index.html. (See https://dworken.keybase.pub/blog/posts/website-hosting-with-... for information on setting this up with Nikola on Linux)

They have started sending out invites to people who wanted to join their beta program. So now they are actually issuing certs.

I'm all out, sorry everyone.

Just sent you an invite. If anyone else needs an invitation, I still have 8 left. Shoot me an email or reply here if you want one.

Edit: 6 still left.

What is your email? I'm not seeing it on your profile.

Got it! Thank you very much.

Any chance I can get one? david@daviddworken.com

If you end up making one, send it to me! I'll happily credit you on the blog post.