Today, we are open sourcing Tetragon after several years of development. eBPF-based Security Observability & Runtime Enforcement.
isovalent.com/blog/post/2022…
9
264
26
782
Correct. Nobody is disagreeing with this. But when an exploit has happened, what else do you want to do other than to stop the malicious code as quickly as possible?
1
1
Obviously when you have Kernel RW you’re free to do anything, the question is what APTs do with that. If they commonly chose to return to userspace as root, than this kind of policies has value. I doubt they try to disable eBPF programs at the moment
1
1
Maybe I misunderstood how Tetragon works, but it should be able to detect earlier when the close() syscall returns. They probably just used a policy that lets the demo play out a bit
2
2
that privilege escalating syscall doesn't need to return to userland for the exploitation process to be successful.
1
21
PaX Team retweeted
Weird, for years Google employees have been dismissing RAP for being incompatible with XOM (despite the latter being pointless with CFI), now suddenly since their employer is pushing KCFI (which tries to be a wanna-be RAP), that concern suddenly vanished: lists.openwall.net/linux-har…
1
1
20
PaX Team retweeted
I will be talking tomorrow about branch predictors and SLS. If this topic is of interest to you, please join me at @hardwear_io webinar (it’s free). #TooManySlidesTooLittleTime
2
8
19
I really wish "Turing complete" as a term would be expunged from discussions of exploits. It simply has no relevance whatsoever.
13
5
1
69
PaX Team retweeted
While ucode 0x22 (as released as part of our blog) fixes the processor bug mentioned therein, ucode 0x24 (released in February) reintroduces it 🤦♂️
Can somebody at Intel *pretty, please* hand the ucode devs a proper source code revision management tool? Thanks!
New blog post from @_minipli : Watch Your Step(ping): Atoms Breaking Apart
grsecurity.net/watch_your_st…
Join us on a deep dive into a customer-reported issue that ended up being an Intel Atom CPU bug unfixed on a specific stepping. A microcode update fixing the issue is provided.
3
21
1
50
@spendergrsec @paxteam After PAX_PRIVATE_KSTACKS, are there any plans to mitigate the race in userland or do you already have mitigations in place?
1
PaX Team retweeted
Slides for @spendergrsec's @bluehatil 2022 keynote: "Compilers: The Old New Security Frontier" are now available at: grsecurity.net/papers
PDF: grsecurity.net/Compilers_The…
PPT (w/ speaker notes): grsecurity.net/Compilers_The…
36
2
70
Love this timeline of attacks and defenses for memory safety!
I covered the pros and cons of the different spatial & temporal memory safety solutions as part of my PhD candidacy presentation. You may want to check it out here (Slides: shorturl.at/muJKO, starting from slide #80 and List: cs.columbia.edu/~mtarek/file…).
4
28
2
138
@paxteam come on, you had this before (infoleak your age ;))
1
2
PaX Team retweeted
Here comes my new blog article describing some more adventures (CVE-2021-26341) with AMD's branch predictor. This time it's kind of a funny story... grsecurity.net/amd_branch_mi…
7
67
8
157
PaX Team retweeted
Join us in Part 2 of @wipawel's research into AMD's branch predictor, starting with a story of his first day working with @opensrcsec analyzing a single byte change to RAP and ending up with a CVE for a new case of Straight-Line Speculation on call/jmp: grsecurity.net/amd_branch_mi…
1
9
19
PaX Team retweeted
Dirty Pipe is a nasty upstream Linux kernel vulnerability affecting Linux >= 5.8, found by Max Kellermann: dirtypipe.cm4all.com/ It allows writing to arbitrary read-only files, similar to DirtyCoW. #grsecurity backported the silent fix in all patches after February 22nd.
1
114
8
250
PaX Team retweeted
OSS President (@spendergrsec) will be giving a keynote Thursday, March 3rd at @bluehatil on the topic of compiler-based security. See you there!
2
1
PaX Team retweeted
Today we present deep research from our @wipawel into the branch predictor of AMD CPUs and abusing its behavior to exploit Spectre v1 much more easily than previously understood, culminating in reproducing an arbitrary kernel mem leak PoC in only 3 days.
grsecurity.net/amd_branch_mi…
5
85
8
219
PaX Team retweeted
Today's #grsecurity beta patch integrates a new defense from @_minipli for a difficult class of vulnerability in the Linux kernel. It will be enhanced with a new GCC plugin in the near future. See the commit log for more information, or soon, an in-depth knowledge base article.
5
1
10
Overheard: "create tooling that kills all classes of vulnerabilities"
- @leolukde
who's in?
2
17
Indeed! Finding individual bugs is great, but systemic risk reduction requires eliminating entire classes of vulnerabilities. Has been true for a long time - some like @paxteam have been preaching it for decades. Took a long time for the industry to accept it... (1/2)
2
8
he did the same to me a few years ago and i stopped his censorship by not sending him anything anymore. linux users lose, he 'wins'.
We provided a fix for the first issue and all necessary backports. The commit message that was provided directly to Linus mentioned "This fixes CVE-2022-22942", but this has been inexplicably removed from the upstream commit: git.kernel.org/pub/scm/linux…
1
8
1
11
after many years of procrastination, private (née unreadable) kstacks are about to graduate from PoC to production. not possible without some existing infrastructure we've developed for UDEREF and other features over a decade ago. payoff++ :)
3
8
31
While the first thing that comes to mind when thinking “kstack” is RANDKSTACK, the first hits on Google point to @jonoberheide’s Stackjacking (paid ads?). Curious about the new feature ;)
1
1
the goal is simple: a given cpu can access only the current kstack, #PF on everyone else's (modulo some complications when such 'foreign' kstack accesses are intended). basically this is similar to what you already have in userland between process stacks.
3
3