Tag: security

Wycheproof

In cryptography, subtle mistakes can have catastrophic consequences, and mistakes in open source cryptographic software libraries repeat too often and remain undiscovered for too long. Good implementation guidelines, however, are hard to come by: understanding how to implement cryptography securely requires digesting decades’ worth of academic literature. We recognize that software engineers fix and prevent bugs with unit testing, and we found that many cryptographic issues can be resolved by the same means. These observations have prompted us to develop Project Wycheproof, a collection of unit tests that detect known weaknesses or check for expected behaviors of some cryptographic algorithm. Our cryptographers have surveyed the literature and implemented most known attacks. As a result, Project Wycheproof provides tests for most cryptographic algorithms, including RSA, elliptic curve crypto, and authenticated encryption.

WebAssembly

Today we’re happy to announce, in tandem with Firefox and Edge, a WebAssembly Browser Preview. WebAssembly or wasm is a new runtime and compilation target for the web, designed by collaborators from Google, Mozilla, Microsoft, Apple, and the W3C WebAssembly Community Group.

2018-08-16: WebAssembly Attacks

WebAssembly is a format that allows code written in assembly-like instructions to be run from JavaScript. It has recently been implemented in all 4 major browsers. We reviewed each browser’s WebAssembly implementation and found 3 vulnerabilities. This blog post gives an overview of the features and attack surface of WebAssembly, as well as the vulnerabilities we found.

2023-01-19: While I still think node.js is a dumb joke, this makes a good point for using wasm instead of containers

The following are a few of the reasons WASM is worth keeping an eye on.

  1. It’s Getting Faster
    Speed is a feature, and those behind the WASM specification have been hard at work. A little over 3 years ago we spoke to some of the core dev team, and their estimation was that WASM came with approximately a 20% performance hit versus native code. They speculated that within 2 years that difference could be erased, or at least made negligible enough to not matter. Today, depending on platform and workload, that has proven to be the case; one provider even claimed recently to run faster within WASM than natively. The performance limitations, therefore, that have held WASM back in the past are largely subsiding, making it viable for more and more workloads.
  2. It’s Quick
    If WASM has been compelled to work on its overall performance, there’s no such need with respect to its latency. Even from cold start situations, WASM’s latency is measured in milliseconds, not actual seconds as is typical with other application platforms from containers to function-as-a-service providers. This makes it highly suitable for workloads that are latency-sensitive, which is more and more workloads – and certainly the event-based workloads that are becoming more common within the enterprise.
  3. It’s (Relatively) Secure
    Granting that no software is immune to vulnerabilities, WASM is nevertheless distinguished in this area. Designed from day one to be secure enough to run executables within the context of an individual’s browser, it is based on sandbox principles, with no access to or from the outside by definition. At a minimum, the historical priority placed on security has been higher than other platforms, a fact likely to be appreciated by security-sensitive enterprise buyers.
  4. It’s Lightweight
    Relative to something like V8 isolates, WASM executables are sizable. But just as containers were much lighter weight than the virtual machines they supplanted, so too is WASM dramatically lighter weight than containers. This means that, properly orchestrated (a subject we’ll come back to), WASM deployments can be fantastically dense relative to their container based peers; one provider reports 20X-30X more WASM sandboxes than Kubernetes containers, for example, on a given piece of hardware. Similarly, Cloudflare has talked about their usage of Isolates to achieve the same goal.

    This density is, in part, why the popular assertion that a growth in WASM deployments will enable something of a renaissance of PaaS platforms seems correct. The unit economics of running platforms – potentially more safely – at dramatically higher densities than container-based alternatives make WASM-based PaaS platforms more viable not only technically but economically as well. Both in terms of their overall end user pricing, but also potentially making free or lower cost tiers possible that have previously been deemed cost prohibitive by vendors such as Heroku.

  5. The Language Support is Improving
    For enterprises used to working with container-based platforms, or virtual machines before that, language limitations are non-existent. Whatever the language and runtime, a given application is wrapped in a container and then run on platforms like Kubernetes alongside hundreds or thousands of other workloads, covering a multitude of languages. But as Fermyon’s language support page indicates, WASM’s support for various programming languages varies, and widely. But this is unlikely to be a fatal flaw for WASM-based providers. First, because the support for new languages is improving, and at an accelerating pace as more attention is focused on the technology. Second, because the set of core languages supported already (C/C++. C#, Go, Kotlin, Rust, Swift etc) cover a large number of potential workloads. And lastly because abstract models like PaaS have always imposed such constraints, and if anything that’s likely to become more common rather than less as more and more abstract models emerge.

Bit-Flipping Attacks

An app containing the researchers’ rooting exploit requires no user permissions and doesn’t rely on any vulnerability in Android to work. Instead, their attack exploits a hardware vulnerability, using a Rowhammer exploit that alters crucial bits of data in a way that completely roots name brand Android devices from LG, Motorola, Samsung, OnePlus, and possibly other manufacturers.

Largest DDoS yet

the attackers behind this record assault launched it from quite a large collection of hacked systems — possibly 100k of systems. “Someone has a botnet with capabilities we haven’t seen before. We looked at the traffic coming from the attacking systems, and they weren’t just from 1 region of the world or from a small subset of networks — they were everywhere.”

Is US Any Safer?

In fact, this may be a path only a lame duck could risk. The politically easier path is to promise “never again.” As Trump’s hard-line rhetoric about the president being weak on terrorism demonstrates, Obama and anyone who follows him and tries to continue on that path will be an easy target for opponents who will claim that transforming homeland security from the fantasy of never-again prevention to a combination of prevention and mitigation and recovery is throwing in the towel. That this is still a debate in an election season 15 years after the 9/11 attacks is evidence that although we’ve made progress, we’re still a long way from adjusting—politically and psychically—to this new normal, where, unlike during the Cold War, there is no relying on deterrence for protection.