Pinned Tweet
I was bored so I wrote an exploit for CVE-2015-6565 affecting OpenSSH 6.8-6.9, considered mostly to be a DoS
openwall.com/lists/oss-secur…
Today I learned that a memory corruption vulnerability may not be considered a memory corruption vulnerability
This Post is from an account that no longer exists. Learn more
1
Looking at a private version of PaX/grsec from the 2nd half of this year, there's no probabilistic xor cookie retaddr protection for the 'iret' insn case. I'm not saying it can't be done & I'm also not saying it isn't implemented in some later or exotic commercial version.
1
nitter.gq/spendergrsec/status/13…
RAP_XOR was added, apparently, on March 11 2020. My work was published on September 2019, so my case still stands. The attack worked at the time, it's that simple.
unavailable
1
nitter.gq/spendergrsec/status/13…
It is an issue. I was specifically told that CAP_SYS_ADMIN -> kernel code exec via code ptr overwrites was within RAP's threat model. "It's less useful" doesn't really stand since otherwise RAP is just as useless in the presence of data-only attacks.
unavailable
Not trying to add fuel to the fire here, but I just got a hold of the private versions of PaX/grsec (one version is a few months before & the other a few months after my work). In the later version the executable .rodata issue is fixed. I was told it was a 'known' 'non-issue'.
Alternatively, there's also no probabilistic xor cookie retaddr protection in any of the versions for either 'ret' or 'iret' insns as claimed.
Replying to @uid1000
section 3.3 is even worse. it shows an 'exploit' by changing memory directly from gdb. it only shows you couldn't even find a real bug or create one yourself to do it for real. second, you missed the fact that the xor cookie defense applies to all return addresses, iret included.
Talking about bruised egos, apparently a certain someone decided to throw a tantrum and block me because he just got nominated for the Lamest Vendor Response award... Isn't it ironic? Good riddance!
1
3
Fun fact: the initial Kaiser (currently KPTI) patches, which were meant to fix KASLR breaks via CPU side-channel attacks (read: not Meltdown), specifically said that KASLR could still be broken. For more, see "challenge 2" from the original paper.
Federico Bento retweeted
Replying to @bluefrostsec @NicoEconomou
I liked the blog but this tweet is pretty dramatic. kASLR was vulnerable to timing attacks prior to Meltdown and we explicitly documented that our Meltdown mitigation does not attempt to solve kASLR. kASLR was never safe from timing attacks nor should anyone have expected it was.
git.kernel.org/pub/scm/linux…… is a cute bug and also a good reminder that one of SMAP's weaknesses is the reliance on EFLAGS.AC
Federico Bento retweeted
Cool writeup exploiting FreeBSD bhyve. Nice to see the same points from other platforms repeat here:
- CFI makes more exploits leak the stack && do ROP (it's easy)
- RFG/SafeStack/whatever in software is weak, many ways to leak the shadow stack address
phrack.org/papers/escaping_f…
Federico Bento retweeted
Interesting facts about 'exec_id' - almost all Linux kernels insufficiently restrict exit signals (except 2.0.39 and 2.0.40 ;-))
blog.pi3.com.pl/?p=697
Federico Bento retweeted
Let's try kernel stack base offset randomization again! :) lore.kernel.org/lkml/2020032…
Federico Bento retweeted
New blog post on Hardware-enforced Stack Protection in Windows 10 from the Windows kernel team (@TheRealHariP & @mamyun)
Support is in WIP fast ring builds if/when you have a CPU that supports CET :)
techcommunity.microsoft.com/…
Federico Bento retweeted
Free knowledge! 🔥 We have a new blog post ready, which discloses an unfixed Linux UserLAnd ASLR bypass. Read here: bit.ly/2ULoj97
--
#cybersecurity #informationsecurity #linux #ASLR #alwayskeeplearning #wildfire #goblaze

















