Potential bypass of Runas user restrictions
> When sudo is configured to allow a user to run commands as an arbitrary user via the ALL keyword in a Runas specification, it is possible to run commands as root by specifying the user ID -1 or 4294967295.
Interesting combination of circumstances.
Chromebook U2F ECDSA vulnerability
> We discovered a vulnerability in the H1 security chip firmware concerning ECDSA signature generation. The firmware code used incompatible transfer instructions when passing a critical secret value to the cryptographic hardware block, resulting in generating secret values of a specific structure and having a significant loss of entropy in the secret value (64 bits instead of 256 bits). We confirmed that the incorrect generation of the secret value allows it to be recovered, which in turn allows the the underlying ECC private key to be obtained. Thus, attackers that have a single pair of signature and signed data can effectively compute the private key, breaking any functionality or protocols that use the key pair in question.
Experimental feature, with an annoying fix. If it had been for real, quite messy.
Bzip2 And The Cve That Wasn’t
> Compiling with the GCC sanitizers and then fuzzing the resulting binaries might find real bugs. But not all such bugs are security issues. When a CVE is filed there is some pressure to treat such an issue with urgency and push out a fix as soon as possible. But taking your time and making sure an issue can be replicated/exploited without the binary being instrumented by the sanitizer is often better.
I don’t think anything went wrong here, but some interesting details.
clamav: denial of service through "better zip bomb"
> Recently David Fifield presented a new variant of a ZIP bomb where by using overlapping segments he was able to achieve very high compression ratios (42kb->5GB, 10MB->281TB).
> However David Fifield commented in the bug report  that the fix is incomplete, by using some slight variations of his methods he could bypass the fix.
This shouldn’t be anything new, but... oops. Plus some commentary about age browsing, etc.
vDSO, 32-bit time, and seccomp
> The seccomp() mechanism is notoriously difficult to use. It also turns out to be easy to break unintentionally, as the development community discovered when a timekeeping change meant to address the year-2038 problem created a regression for seccomp() users in the 5.3 kernel. Work is underway to mitigate the problem for now, but seccomp() users on 32-bit systems are likely to have to change their configurations at some point.
The problems inherent in exposing very low level interfaces in one place (seccomp) and high level interfaces in another (libc).
> For two years I’ve been driving myself crazy trying to figure out the source of a driver problem on OpenBSD: interrupts never arrived for certain touchpad devices. A couple weeks ago, I put out a public plea asking for help in case any non-OpenBSD developers recognized the problem, but while debugging an unrelated issue over the weekend, I finally solved it. It’s been a long journey and it’s a technical tale, but here it is.
Diving deep into the AML.
Adventures in application compatibility: Calling an internal function
> Of course, searching memory for a function to call is not exactly something documented and supported. Windows made some changes to how these functions operate, and that threw off their code that grovels the binary, and they ended up calling the wrong function.
OpenSSH Taking Minutes To Become Available, Booting Takes Half An Hour ... Because Your Server Waits For A Few Bytes Of Randomness
> Basically as of now the entropy file saved as /var/lib/systemd/random-seed will not - drumroll - add entropy to the random pool when played back during boot. Actually it will. It will just not be accounted for. So Linux doesn’t know. And continues blocking getrandom(). This is obviously different from SysVinit times2 when /var/lib/urandom/random-seed (that you still have lying around on updated systems) made sure the system carried enough entropy over reboot to continue working right after enough of the system was booted.
And then... it just kinda keeps getting worse. The problem is understandable, the inability to resolve it less so.
The lifetime of an Android API vulnerability
> When we published our paper in 2015, we predicted that this vulnerability would not be patched on 95% of devices in the Android ecosystem until January 2018 (plus or minus a standard deviation of 1.23 years). Since this date has now passed, we decided to check whether our prediction was correct.
> The good news is that we found the operating system update requirements crossed the 95% threshold in May 2017, seven months earlier than our best estimate, and within one standard deviation of our prediction. The most recent data for May 2019 shows deployment has reached 98.2% of devices in use. Nevertheless, fixing this aspect of the vulnerability took well over 4 years to reach 95% of devices.
Provide protection against starvation of the ll/sc loops when accessing userpace.
> Casueword(9) on ll/sc architectures must be prepared for userspace constantly modifying the same cache line as containing the CAS word, and not loop infinitely. Otherwise, rogue userspace livelock kernel.
Understanding real-world concurrency bugs in Go
> We perform the first systematic study on concurrency bugs in real Go programs. We studied six popular Go software [projects] including Docker, Kubernetes, and gRPC. We analyzed 171 concurrency bugs in total, with more than half of them caused by non-traditional, Go-specific problems. Apart from root causes of these bugs, we also studied their fixes, performed experiments to reproduce them, and evaluated them with two publicly-available Go bug detectors.
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.
Alpine Linux Docker Image root User Hard-Coded Credential Vulnerability
> Versions of the Official Alpine Linux Docker images (since v3.3) contain a NULL password for the root user. This vulnerability appears to be the result of a regression introduced in December t2015. Due to the nature of this issue, systems deployed using affected versions of the Alpine Linux container that utilize Linux PAM, or some other mechanism that uses the system shadow file as an authentication database, may accept a NULL password for the root user.
NULL as in empty. Note the timeline.
> This vulnerability was originally reported and patched in 2015, regression tests were added to prevent this from occurring in the future.
> Unfortunately, later that same year, a commit was pushed to simplify the regression tests. This lead to logic that may have caught this regression being simplified, causing these tests to be incorrectly ‘satisfied’ if the root password was once again removed.
> Eight days after this vulnerability was initially fixed, a commit was pushed which removed this ‘disable root by default’ flag from the ‘edge’ build properties file, reintroducing this issue to subsequent builds.
ufs - Expand time_t support to 48 bits
> Fix time overflow issues in the original 32-bit UFS code in two ways. First, treat the original 32-bit seconds fields as unsigned.Second, utilize the spare fields to expand these fields to 48 bits each. Retain the nanosecond-grain accuracy of the nsec fields.
Categorizing OpenBSD Bugs
> I went through two years of OpenBSD errata for the most recent four releases (6.1, 6.2, 6.3 and 6.4) and categorized each bug.
XSA-294 - x86 shadow: Insufficient TLB flushing when using PCID
> Use of Process Context Identifiers (PCID) was introduced into Xen in order to improve performance after XSA-254 (and in particular its Meltdown sub-issue). This enablement implied changes to the TLB flushing logic. One aspect which was overlooked is the safety of switching between shadow pagetables, which previously relied on the unconditional flushing of a write to CR3.
> With PCID enabled, a switch of shadow pagetable for a 64bit PV guest fails to invalidate the linear mappings of the previous shadow pagetable. As a result, subsequent accesses to the shadow pagetables may be deemed to be safe by the shadow logic (based on the old shadow pagetable) but fault when made in practice.
default to OXTABS off
> Almost all terminals now support hardware tabs so default to OXTABS off.
The future is here!
Most long-standing XHCI (USB 3.0+) issues resolved!
> Well, just under a month (and ~40 commits) later, virtually all those issues have been resolved. There’s a good bit of work that remains to be done, but at least all (!) the kernel panics are resolved, devices (largely) don’t lock up without an explanation (there are a few exceptions, but not many), performance is greatly improved (40MB/s with random 1-2s-long stalls, to 120MB/s on some USB3 flash drives and XHCI chipsets), and XHCI-attached keyboards can even be used in KDL!
The data structures were not initialized
> /////// Initialize data structures \\\\\\\
Never comment your code. Problem solved.
Understanding Real-World Concurrency Bugs in Go
> In this paper, we perform the first systematic study on concurrency bugs in real Go programs. We studied six popular Go software including Docker, Kubernetes, and gRPC. We analyzed 171 concurrency bugs in total, with more than half of them caused by non-traditional, Go-specific problems. Apart from root causes of these bugs, we also studied their fixes, performed experiments to reproduce them, and evaluated them with two publicly-available Go bug detectors. Overall, our study provides a better understanding on Go’s concurrency models and can guide future researchers and practitioners in writing better, more reliable Go software and in developing debugging and diagnosis tools for Go.