papers, talks, tools, etc
There is a secret that needs to be understood in order to write good software documentation: there isn’t one thing called documentation, there are four.
They are: tutorials, how-to guides, technical reference and explanation. They represent four different purposes or functions, and require four different approaches to their creation. Understanding the implications of this will help improve most documentation – often immensely.
Source: https://documentation.divio.com/
As organizations mature, they develop more tools. At Google, we continually create new external and internal services, as well as infrastructure to support these services. By 2013, we started outgrowing the simple automation workflows we used to update and maintain our services. Each service required complex update logic, and had to sustain infrastructure changes, frequent cluster turnups and turndowns, and more. The workflows for configuring multiple, interacting services were becoming hard to maintain— when they even existed. We needed a new solution to keep pace with the growing scale and variety of configurations involved. In response, we developed a declarative automation system that acts as a unified control plane and replaces workflows for these cases. This system consists of two main tools: Prodspec, a tool to describe a service’s infrastructure, and Annealing, a tool that updates production to match the output of Prodspec. This article discusses the problems we had to solve and the architectural choices we made along the way.
In this paper, we study the efficacy of login challenges at preventing
account takeover, as well as evaluate the amount of friction these
challenges create for normal users. These secondary authentication
factors—presently deployed at Google, Microsoft, and other major
identity providers as part of risk-aware authentication—trigger in
response to a suspicious login or account recovery attempt. Using
Google as a case study, we evaluate the effectiveness of fourteen
device-based, delegation-based, knowledge-based, and resourcebased challenges at preventing over 350,000 real-world hijacking
attempts stemming from automated bots, phishers, and targeted
attackers. We show that knowledge-based challenges prevent as
few as 10% of hijacking attempts rooted in phishing and 73% of
automated hijacking attempts. Device-based challenges provide the
best protection, blocking over 94% of hijacking attempts rooted in
phishing and 100% of automated hijacking attempts. We evaluate
the usability limitations of each challenge based on a sample of
1.2M legitimate users. Our results illustrate that login challenges
act as an important barrier to hijacking, but that friction in the
process leads to 52% of legitimate users failing to sign-in—though
97% of users eventually access their account in a short period
Traffic monetization is a crucial component of running most forprofit online businesses. One of its latest incarnations is cryptocurrency mining, where a website instructs the visitor’s browser to
participate in building a cryptocurrency ledger in exchange for a
small reward in the same currency.
In its essence, this practice trades the user’s electric bill, or battery level, for cryptocurrency. With user consent, this exchange
can be a legitimate funding source – for example, UNICEF is collecting donations in this fashion on thehopepage.org. Regrettably,
this practice also easily lends itself to abuse: in this form, called
cryptojacking, attacks surreptitiously mine in the users browser,
and profits are collected either by website owners or by hackers
that planted the mining script into a vulnerable page.
Understandably, users frown upon this practice and have sought
to mitigate it by installing blacklist-based browser extensions (the
top 3 for Chrome total over one million installs), whereas researchers
have devised more robust methods to detect it. In turn, cryptojackers have been bettering their evasion techniques, incorporating
in their toolkits domain fluxing, content obfuscation, the use of
WebAssembly, and throttling. The latter, in particular, grew from
being a niche feature, adopted by only one in ten sites in 2018 [18],
to become commonplace in 2019, reaching an adoption ratio of 58%.
Whereas most state-of-the-art defenses address multiple of these
evasion techniques, none is resistant against all.
In this paper, we offer a novel detection method, CoinPolice,
that is robust against all of the aforementioned evasion techniques.
CoinPolice flips throttling against cryptojackers, artificially varying
the browser’s CPU power to observe the presence of throttling.
Based on a deep neural network classifier, CoinPolice can detect
97.87% of hidden miners with a low false-positive rate (0.74%). We
compare CoinPolice performance with the current state of the art
and show our approach outperforms it when detecting aggressively
throttled miners.
Finally, we deploy Coinpolice to perform the largest-scale cryptoming investigation to date, identifying 6700 sites that monetize
traffic in this fashion.
With tons of efforts spent on its mitigation, Crosssite scripting (XSS) remains one of the most prevalent security
threats on the internet. Decades of exploitation and remediation
demonstrated that code inspection and testing alone does not
eliminate XSS vulnerabilities in complex web applications with
a high degree of confidence.
This paper introduces Google’s secure-by-design engineering
paradigm that effectively prevents DOM-based XSS vulnerabilities in large-scale web development. Our approach, named
API hardening, enforces a series of company-wide secure coding
practices. We provide a set of secure APIs to replace native
DOM APIs that are prone to XSS vulnerabilities. Through a
combination of type contracts and appropriate validation and
escaping, the secure APIs ensure that applications based thereon
are free of XSS vulnerabilities. We deploy a simple yet capable
compile-time checker to guarantee that developers exclusively
use our hardened APIs to interact with the DOM. We make
various of efforts to scale this approach to tens of thousands
of engineers without significant productivity impact. By offering
rigorous tooling and consultant support, we help developers adopt
the secure coding practices as seamlessly as possible. We present
empirical results showing how API hardening has helped reduce
the occurrences of XSS vulnerabilities in Google’s enormous code
base over the course of two-year deployment.
Index Terms—Web security, cross-site scripting, languagebased security, empirical software engineering
Fuzzing is a key tool used to reduce bugs in production software. At
Google, fuzzing has uncovered tens of thousands of bugs. Fuzzing
is also a popular subject of academic research. In 2020 alone, over
120 papers were published on the topic of improving, developing,
and evaluating fuzzers and fuzzing techniques. Yet, proper evaluation of fuzzing techniques remains elusive. The community has
struggled to converge on methodology and standard tools for fuzzer
evaluation.
To address this problem, we introduce FuzzBench as an opensource turnkey platform and free service for evaluating fuzzers.
It aims to be easy to use, fast, reliable, and provides reproducible
experiments. Since its release in March 2020, FuzzBench has been
widely used both in industry and academia, carrying out more than
150 experiments for external users. It has been used by several
published and in-the-work papers from academic groups, and has
had real impact on the most widely used fuzzing tools in industry.
The presented case studies suggest that FuzzBench is on its way
to becoming a standard fuzzer benchmarking platform
Slides from two day course on Vanadium https://vanadium.github.io/
Source: http://www.sti.uniurb.it/events/fosad16/Taly-Day2.pdf
The record layer is the main bridge between TLS applications and internal sub-protocols. Its core functionality is an elaborate form of authenticated encryption: streams of messages for each sub-protocol (handshake, alert, and application data) are fragmented, multiplexed, and encrypted with optional padding to hide their lengths. Conversely, the sub-protocols may provide fresh keys or signal stream termination to the record layer. Compared to prior versions, TLS 1.3 discards obsolete schemes in favor of a common construction for Authenticated Encryption with Associated Data (AEAD), instantiated with algorithms such as AES-GCM and ChaCha20-Poly1305. It differs from TLS 1.2 in its use of padding, associated data and nonces. It also encrypts the content-type used to multiplex between sub-protocols. New protocol features such as early application data (0-RTT and 0.5-RTT) and late handshake messages require additional keys and a more general model of stateful encryption. We build and verify a reference implementation of the TLS record layer and its cryptographic algorithms in F*, a dependently typed language where security and functional guarantees can be specified as pre-and post-conditions. We reduce the high-level security of the record layer to cryptographic assumptions on its ciphers. Each step in the reduction is verified by typing an F* module, for each step that involves a cryptographic assumption, this module precisely captures the corresponding game. We first verify the functional correctness and injectivity properties of our implementations of one-time MAC algorithms (Poly1305 and GHASH) and provide a generic proof of their security given these two properties. We show the security of a generic AEAD construction built from any secure one-time MAC and PRF. We extend AEAD, first to stream encryption, then to length-hiding, multiplexed encryption. Finally, we build a security model of the record layer against an adversary that controls the TLS sub-protocols. We compute concrete security bounds for the AES_128_GCM, AES_256_GCM, and CHACHA20_POLY1305 ciphersuites, and derive recommended limits on sent data before re-keying. We plug our implementation of the record layer into the miTLS library, confirm that they interoperate with Chrome and Firefox, and report initial performance results. Combining our functional correctness, security, and experimental results, we conclude that the new TLS record layer (as described in RFCs and cryptographic standards) is provably secure, and we provide its first verified implementation.
Source: https://www.microsoft.com/en-us/research/publication/implementing-proving-tls-1-3-record-layer/
“Retpoline” sequences are a software construct which allow indirect branches to be isolated from speculative execution. This may be applied to protect sensitive binaries (such as operating system or hypervisor implementations) from branch target injection attacks against their indirect branches.
The name “retpoline” is a portmanteau of “return” and “trampoline.” It is a trampoline construct constructed using return operations which also figuratively ensures that any associated speculative execution will “bounce” endlessly.
(If it brings you any amusement: imagine speculative execution as an overly energetic 7-year old that we must now build a warehouse of trampolines around.)
things i find on the web 