> This library implements application-guided rewriting of binary functions at runtime. Binary functions can be optimized and specialized based on runtime information. In contrast to transparent binary optimization, only selected binary functions are rewritten. No metadata (e.g. debug information) is required.

source: E

If you don’t have time for the challenges themselves, reading this review a few times until the lessons are internalized may be a good substitute.

> How practical these attacks were. A lot of stuff that I knew was weak in principle (like re-using a nonce or using a timestamp as a ‘random’ seed) turns out to be crackable within seconds by an art major writing crappy Python.

https://cryptopals.com/

source: grugq

> I often find it valuable to write simple test cases confirming things work the way I think they do. Sometimes I can’t explain the results, and getting to the bottom of those discrepancies can reveal new research opportunities. This is the story of one of those discrepancies; and the security rabbit-hole it led me down.

> Any application, any user - even sandboxed processes - can connect to any CTF session. Clients are expected to report their thread id, process id and HWND, but there is no authentication involved and you can simply lie. Secondly, there is nothing stopping you pretending to be a CTF service and getting other applications - even privileged applications - to connect to you.

> Even without bugs, the CTF protocol allows applications to exchange input and read each other’s content. However, there are a lot of protocol bugs that allow taking complete control of almost any other application.

https://github.com/taviso/ctftool

Regarding disclosure: https://bugs.chromium.org/p/project-zero/issues/detail?id=1859#c10

> 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.

source: L

> There is a class of UI performance problems that arise from the following situation: An input event is firing faster than the browser can paint frames.

> In a previous post, I discussed Lodash’s debounce and throttle functions, which I find very useful for these kinds of situations. Recently however, I found a pattern I like even better, so I want to discuss that here.

Follow up: https://nolanlawson.com/2019/08/14/browsers-input-events-and-frame-throttling/

source: L

> Almost a year ago I did a write-up on KTRR, first introduced in Apple’s A10 chip series. Now over the course of the last year, there has been a good bit of talk as well as confusion about the new mitigations shipped with Apple’s A12. One big change, PAC, has already been torn down in detail by Brandon Azad, so I’m gonna leave that out here. What’s left to cover is more than just APRR, but APRR is certainly the biggest chunk, hence the title of this post.

> APRR is a pretty cool feature, even if parts of it are kinda broke. What I really like about it (besides the fact that it is an efficient and elegant solution to switching privileges) is that it untangles EL1 and EL0 memory permissions, giving you more flexibility than a standard ARMv8 implementation. What I don’t like though is that it has clearly been designed as a lockdown feature, allowing you only to take permissions away rather than freely remap them.

> It’s also evident that Apple is really fond of post-exploit mitigations, or just mitigations in general. And on one hand, getting control over the physical address space is a good bit harder now. But on the other hand, Apple’s stacking of mitigations is taking a problematic turn when adding new mitigations actively creates vulnerabilities now.

source: L

Here be dragons.

> 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).

source: HN

Time zones, leap seconds, oh my.

I like this much more than the typical falsehoods list because it actually explains the problem and gives a hint about the solution.

> The “best practice” solution is a technique known as suffix trees, which requires some moderately complex coding. However, we can get very reasonable performance for strings up to hundreds of thousands of characters long using a much simpler approach.

source: HN

> Software performance depends more and more on exploiting multiple processor cores. The free lunch from Moore’s Law is still over. Well, we here in the Julia developer community have something of a reputation for caring about performance. In pursuit of it, we have already built a lot of functionality for multi-process, distributed programming and GPUs, but we’ve known for years that we would also need a good story for composable multi-threading. Today we are happy to announce a major new chapter in that story. We are releasing a preview of an entirely new threading interface for Julia programs: general task parallelism, inspired by parallel programming systems like Cilk, Intel Threading Building Blocks (TBB) and Go. Task parallelism is now available in the v1.3.0-alpha release, an early preview of Julia version 1.3.0 likely to be released in a couple months. You can find binaries with this feature on the downloads page, or build the master branch from source.

source: L

> Earlier this year I pushed a small library to Github called Map Guard. The goal of Map Guard is to enforce non-invasive security policies with regards to how pages of memory may be allocated, or modified, with the mmap syscall. For example, we may want to deny any page allocations marked Read, Write, and Execute as it introduces an easy mechanism for an exploit developer to take advantage of. In the rest of this post I will break down the approach I took to implement each of these security policies, and finally how Map Guard uses Intel’s Memory Protection Keys to allow transparently enabling Execute Only memory for all regions of mapped code.

source: grugq

> During one of our engagements, we analyzed an application which used the Jackson library for deserializing JSONs. In that context, we have identified a deserialization vulnerability where we could control the class to be deserialized. In this article, we want to show how an attacker may leverage this deserialization vulnerability to trigger attacks such as Server-Side Request Forgery (SSRF) and remote code execution.

source: green

> Much of the credit goes to folks much smarter than myself (they will be introduced); this tutorial is meant to curate previous work and literature as much as it is for myself to educate you. The goal here is to allow for any curious, technically-minded newcomer to make sense of all the concepts involved in creating compression quines.

source: L

Last post in series, toc at the top.

> 0x00: New Series: Getting Into Browser Exploitation

> 0x01: Setup and Debug JavaScriptCore / WebKit

> 0x02: The Butterfly of JSObject

> 0x03: Just-in-time Compiler in JavaScriptCore

> 0x04: WebKit RegExp Exploit addrof() walk-through

> 0x05: The fakeobj() Primitive: Turning an Address Leak into a Memory Corruption

> 0x06: Revisiting JavaScriptCore Internals: boxed vs. unboxed

> 0x07: Preparing for Stage 2 of a WebKit exploit

> 0x08: Arbitrary Read and Write in WebKit Exploit

source: grugq

> Transparency may not seem particularly exciting. The GIF image format which allowed some pixels to show through the background was published over 30 years ago. Almost every graphic design application released in the last two decades has supported the creation of semi-transparent content. The novelty of these concepts is long gone.

> With this article I’m hoping to show you that transparency in digital imaging is actually much more interesting than it seems – there is a lot of invisible depth and beauty in something that we often take for granted.

source: L

> I’ll be starting to publish a series that is written to aid new and interested readers with building, testing, and understanding type-2 hypervisor development. This hypervisor will be written for use on Intel processors with virtualization support. If you’re operating on an AMD chip, you may find some parts helpful, but overall it may not be what you need to understand the nuances. All concepts for each article, their importance, the references to more detailed information, and otherwise will be linked through just like any other of my blog posts followed by a recommended reading section at the end should your thirst for details and knowledge not be satisfied. I will also put recommended reading for those of you with interest in developing an AMD SVM.

There’s a lot here.

https://revers.engineering/day-0-virtual-environment-setup-scripts-and-windbg/

https://revers.engineering/day-1-introduction-to-virtualization/

https://revers.engineering/day-2-entering-vmx-operation/

https://revers.engineering/day-3-multiprocessor-initialization-error-handling-the-vmcs/

https://revers.engineering/day-4-vmcs-segmentation-ops/

https://revers.engineering/day-5-vmexits-interrupts-cpuid-emulation/

source: grugq

> Kernel headers are usually unavailable on the target where these BPF tracing programs need to be dynamically compiled and run. That is certainly the case with Android, which runs on billions of devices. It is not practical to ship custom kernel headers for every device. My solution to the problem is to embed the kernel headers within the kernel image itself and make it available through the sysfs virtual filesystem (usually mounted at /sys) as a compressed archive file (/sys/kernel/kheaders.tar.xz). This archive can be uncompressed as needed to a temporary directory. This simple change guarantees that the headers are always shipped with the running kernel.

I feel this is the wrong solution, but interesting nevertheless.

source: HN

This covers a lot of ground. I liked this quote, even though there’s much more to the post.

> Canonicalization is a quagnet, which is a term of art in vulnerability research meaning quagmire and vulnerability magnet. You can tell it’s bad just by how hard it is to type ‘canonicalization’.

source: HN

From https://blog.containo.us/announcing-yaegi-263a1e2d070a

> Despite being static and strongly typed, Go feels like a dynamic language. The standard library even provides the Go parser used by the compiler and the reflection system to interact dynamically with the runtime. So why not just take the last logical step and finally build a complete Go interpreter?

> Programming languages for high level scripting and for low level implementation are usually different. This time, with Go, we have an opportunity to unify both. Imagine all the C/C++/Java fast libraries for Python being written in Python instead. That’s what Yaegi is for Go (or, the reverse). No burden due to syntax switch, no need to rewrite or modify slow code to make it fast, and full access to goroutines, channels, type safety, etc. at script level.

source: HN