pfg

How was the disclosure irresponsible? AIUI, multiple attempts were made to report the bug. It went viral a couple of days later on social media. I'm not aware of a link between those two events.

Public disclosure once patches are available is a fairly common policy. Google's Project Zero operates like that as well.

Chrome's implementation solves this by racing a TCP connection with the QUIC connection.

The GCP move was decided upon months before Microsoft acquired GitHub[1].

[1]: https://venturebeat.com/2018/04/06/why-and-how-gitlab-abando...

It's certainly not an interpretation I'd punish a CA for, the language in section 3.2.2.8 is rather ambiguous.

Let's Encrypt is running a fail-close setup for DNSSEC, so I wouldn't quite say it's too unreliable in this particular context. Still, it's quite clear that DNSSEC's complexity is getting in the way of things here. A solution just for this specific use-case would be much simpler overall, and I'm not buying into any of the other benefits DNSSEC claims to bring, so I'd rather just see it die.

The magic sauce would be CAA. This is under the assumption that all publicly trusted CAs respect CAA and have no bypass bugs (CAs probably aren't ... too far off target) and that they properly validate DNSSEC (good luck with that, I don't think there's even consensus on what the Baseline Requirements consider compliant).

Anyway, in this mostly hypothetical world where all of that works as intended, you could use a CAA record with just one or two CAs with which you have some kind of contractual relationship requiring out-of-band verification. Alternatively (and, IMO, preferable, since the controls are technical), you can use the ACME CAA extension[1] to lock down the validation methods to just DNS-based ones, or bind the the whole validation flow to a key. Let's Encrypt is working on this currently[2].

[1]: https://tools.ietf.org/html/draft-ietf-acme-caa-05#section-4

[2]: https://community.letsencrypt.org/t/acme-caa-validationmetho...

In the modern Web PKI, it seems to me that the only thing DNSSEC is good for is mitigating BGP hijacking and similar attacks (in combination with CAA and either some contractual agreement with your CA or the ACME CAA extension).

That's an important issue to solve, but you wouldn't need anything with the complexity and baggage of DNSSEC to do that.

DNSSEC, to a degree, stands in the way of a better solution. And while I have no problem with people using DNSSEC as an additional layer of defense as such, I feel like there's a risk that people will use it as the only layer of defense if it becomes a success, effectively blindly trusting DNS.

Note that I was referring to client/stub resolvers specifically. Last time I checked, it was rather uncommon for them to perform their own DNSSEC validation rather than trusting the AD bit sent by their upstream resolver. In practice that means any MitM between you and your DNS resolver can spoof DNS regardless of DNSSEC status. DoH/DoT, on the other hand, mitigates this.

> Right now there are no benefits though.

In terms of privacy, I would mostly agree. Using an authenticated channel to your resolver still protects against many common MitM vectors, so there's definitely a benefit there. Unlike DNSSEC, you're not dependent on the target domain being in the small subset of DNSSEC-enabled domains, not to mention that most client resolvers won't validate DNSSEC anyway.

It's important to note that DNSSEC does not provide encryption. Additionally, very few client resolvers validate DNSSEC. In typical MitM scenarios, DNS over TLS or HTTPS provides much better protection. If the resolver happens to validate DNSSEC, you're probably adding a bit of protection for other scenarios, but overall I'd still rather not see DNSSEC succeed.

The confidentiality win is not huge, most use-cases will let an attacker make a good guess at the query through the destination IP (for IPs serving only one site) or via SNI. Still, there's definitely a win for other types of queries, and it'll get more useful once we figure out how to encrypt SNI.

In this attack, the maintainer's primary device was not owned. The maintainer's npm account was breached due to a reused password. Code signing would mitigate this because the attacker would be unable to release/sign a malicious version of the package.

Building a system that is immune against the maintainer's device being compromised puts you into "Reflections on trusting trust" territory. Just sticking two-factor authentication into that process won't change much (though it would of course also mitigate the password reuse vector).

What you'd want is for the owner/maintainer to sign the code, rather than the repository. This wouldn't protect you against a malicious maintainer, but it would help in a case like this as long as the signing key or the maintainer's device isn't compromised along with their credentials. That would definitely raise the bar for attacks of this nature.

Does your approach respect TTL, i.e. by updating your source of truth after a record expires? Because you'd still be affected by DNS rebinding attacks in that case - and if not, I imagine there'd be quite a bit of breakage when IPs change?

DNS caching in combination with an enforced minimum TTL (of something like 60 seconds) can be useful in mitigating certain categories of rebinding attacks (for example an attempt to bypass SSRF checks). Your solution might share this property if it behaves similarly.

One could argue that things like the Infineon prime number generator weakness affecting RSA keys are much more severe than this, but honestly, just flip a coin until modern curves become viable for typical smartcard use-cases.

You're thinking of HPKP and other certificate and key-pinning implementations. HSTS only enforces HTTPS, it does not prevent the usage of things like mitmproxy with custom roots added to your trust store.

> But because the fines are so steep — violating GDPR will cost a company 4 percent of its global turnover or $20 million, whichever is larger — no one really wants to be caught non-compliant.

Can everyone just stop repeating this, pretty please? That is the maximum penalty. You'd have to try really, really hard to get that kind of penalty. For minor transgressions, you're likely to get away with a reprimand.

Presumably the legal basis would've been the Bundesdatenschutzgesetz, which is Germany's implementation of the DPD. The DPD itself is not very specific, only saying "such a data protection official, whether or not an employee of the controller, must be in a position to exercise his functions in complete independence;". The language in the Bundesdatenschutzgesetz itself[1] is quite similar to the DPO language in the GDPR.

[1]: https://www.gesetze-im-internet.de/bdsg_1990/__4f.html

This is not about advertising or any kind of misuse of the data. Rather, IT's role is very much one where they they setup and maintain systems and procedures that process data. It's certainly true that GDPR compliance is something an IT person will have to think about, but making the same employee responsible for auditing that things are compliant is quite a bit of a conflict. Auditing versus accounting is a similar concept.

> It seems to me a bit of a stretch that working in IT is a conflict of interest with adhering to data processing regulations; ensuring that your infrastructure is compliant is generally one of the remits of the IT function.

That's a bit like saying auditing/compliance is something that you might as well let the accounting department take care of. It's certainly true that making sure you're compliant with various regulations is a large part of what someone in accounting does, but it seems pretty clear that you can't let the same person be the auditor as well without a conflict of interest, and that's roughly what the role of a data protection officer is all about.

There's some evidence that data protection authorities share this view; a German authority fined a company after they appointed the IT manager as their DPO[1] (sorry, German-only source). It might be too early to say for sure how this will play out, but I wouldn't gamble on data protection authorities accepting just any IT employee unless they're working in some very specific role that prevents any conflict of interest.

[1]: https://www.lda.bayern.de/media/pm2016_08.pdf

Depending on the organization, it can be quite hard to find someone who does not have a conflict of interest while still having the necessary skills to act as a Data Protection Officer. As an example, someone working in IT might have the necessary skill, but is likely to have a conflict of interest because part of their duty as a DPO would be to inspect their own work.

I'm not sure what you're trying to say here, but Enigmail 2 was released a few months after the researchers disclosed the vulnerability to the project[1], so it would've been a rather sad state of affairs if the release hadn't included a fix. That's not to say that everything's fine now for users of Thunderbird and Enigmail[2].

[1]: https://sourceforge.net/p/enigmail/bugs/721/

[2]: https://twitter.com/hanno/status/997138771194859521

Signal merged support for devices without Play Services about a year ago. Is that what you're looking for?

There's a bit of an explanation of this in the article describing the other XSS that's recently been found in Signal[1]. Basically, since the Electron app itself runs under the file:// origin, 'self' can be bypassed with varying degrees of difficulty depending on the platform. On Windows, it's trivial because you can use UNC paths to a SMB share containing a malicious JavaScript file (i.e. file://1.2.3.4/payload.js). On other platforms, you'd need to find a way to place the file on a path accessible via file:// first, for example by sending the file via Signal itself and hoping the user accepts the download.

There are ways to lock down the CSP further to mitigate this, but no one really expects script-src 'self' to be unsafe, especially when it's what their documentation recommends.

[1]: https://ivan.barreraoro.com.ar/signal-desktop-html-tag-injec...

So to be clear, a lot of the blame definitely belongs in the "all that comes with it" bucket here, which is one of the reasons why you should think twice about developing desktop apps using a platform that forces you to deal with not only the usual desktop app security concerns, but also all the things that make web apps vulnerable.

Still, when you ship an app with a relatively strict Content Security Policy as Signal did (including using script-src 'self'), you don't really expect a simple XSS vulnerability to lead to RCE, but it turns out that policy doesn't really do much in an Electron app.

> Thunderbird does not download remote content by default.

The researchers behind EFAIL found a number of ways to bypass the remote content setting. Not only that, but Hanno Böck found another one today[1] that hasn't been fixed yet.

[1]: https://twitter.com/hanno/status/997138771194859521

As much as I'm not a fan of JavaScript, the problem is not so much the language but rather the choice of Electron and all that comes with it. Heck, even a web version or Chrome app would've successfully mitigated these attacks. Electron means you're one XSS away from remote code execution, and even worse, it makes it way harder to mitigate XSS through CSP (which Signal did utilize, but script-src 'self' can easily be bypassed in Electron).

FWIW, Signal's native mobile apps are written in Java and Objective-C respectively, so there's not really much of a difference compared to Wire (which is a good choice as well). Still, even a hypothetical React Native app written in JavaScript wouldn't be much worse; after all, React Native isn't just a Web View made to look like a native app, but uses actual native components.

YubiKeys are non-upgradable by design. This is occasionally annoying when new standards come out and you need to go buy new keys (which is not something that's gonna happen a lot), but it significantly reduces the attack surface of these devices. They've been pretty good about giving out free replacement keys whenever major flaws have been found, and webauthn is pretty good about remaining backwards-compatible with U2F keys, so I don't think it's something they handled particularly badly.

I don't know about 7-Zip specifically, but AV vendors use plenty of FOSS code. Here's some findings just from Google's P0 showing that Symantec[1], Bitdefender[2], Microsoft[3] and Avast[4] all use unrar in their products. It wouldn't be far-fetched to assume some might use 7-Zip for other archive formats.

[1]: https://bugs.chromium.org/p/project-zero/issues/detail?id=81...

[2]: https://bugs.chromium.org/p/project-zero/issues/detail?id=12...

[3]: https://bugs.chromium.org/p/project-zero/issues/detail?id=15...

[4]: https://bugs.chromium.org/p/project-zero/issues/detail?id=57...

> To be fair to virus scanner vendors, the only way to mitigate this kind of bug is NIH: don't use 3rd party libs, implement everything yourself. But then, of course, without bugs yourself, as well :)

That is not the only way to mitigate such vulnerabilities. AV vendors have had plenty of time to work on sandboxing parts of their scan engines that have repeatedly been found to have vulnerabilities like this one. Somehow we've arrived at a point where no one would recommend using a browser that doesn't utilize sandboxing to some degree, but when it comes to security products, you can count yourself lucky if they don't just run that code as SYSTEM. That should really tell you all you need to know about the state of the AV industry.

The segmentation code is keyframe-aware, so it only splits along keyframe edges. In other words: requesting segments of 30 seconds each probably won't get you segments that are exactly 30 seconds long. Still, there could be plenty of other obstacles I'm not aware of.