|
Carthag Tuek posted:nets (the company that runs nemid) just got swallowed by an italian company called nexi so... 
|
#
?
Mar 19, 2021 17:55
|
|
|
|
| # ? Apr 23, 2024 14:52 |
|
|
Carthag Tuek posted:nets (the company that runs nemid) just got swallowed by an italian company called nexi so... just wire me already, you’ll at least know your money will be spent on mundane poo poo like dental implant
|
|
#
?
Mar 19, 2021 20:08
|
|
|
Carthag Tuek posted:nets (the company that runs nemid) just got swallowed by an italian company called nexi so... Anectodal since I’ve interacted with them in the past but Nexi(formerly known as CartaSI) is the sole entity in Italy that has been able to roll out every tokenized payment in existence(including Garmin and Samsung pay) while the rest of the banks had a thumb deep in their asses, they are far from the dumbest entity you could interact in the sector. Most banks here are now dropping their current in-house systems to a nexi-provided solution to not look like assholes.
|
|
#
?
Mar 19, 2021 20:40
|
|
|
BlankSystemDaemon posted:welp, this is gonna be fun then, can't wait lookin forward to ic3 version 2.0 lmao e: SlowBloke posted:Anectodal since I’ve interacted with them in the past but Nexi(formerly known as CartaSI) is the sole entity in Italy that has been able to roll out every tokenized payment in existence(including Garmin and Samsung pay) while the rest of the banks had a thumb deep in their asses, they are far from the dumbest entity you could interact in the sector. Most banks here are now dropping their current in-house systems to a nexi-provided solution to not look like assholes. okay tbf that doesnt sound terrible
|
|
#
?
Mar 19, 2021 20:46
|
|
|
does anyone maintain a comprehensive list of APT group labels that get used?
|
|
#
?
Mar 19, 2021 21:12
|
|
|
Trabisnikof posted:does anyone maintain a comprehensive list of APT group labels that get used? https://askubuntu.com/a/27515 but seriously, I've always leaned on https://www.fireeye.com/current-threats/apt-groups.html
|
|
#
?
Mar 19, 2021 21:18
|
|
|
Trabisnikof posted:does anyone maintain a comprehensive list of APT group labels that get used? the FBI probably does
|
|
#
?
Mar 19, 2021 21:20
|
|
|
Sassafras posted:https://askubuntu.com/a/27515 lol and thanks
|
|
#
?
Mar 19, 2021 21:21
|
|
|
Trabisnikof posted:does anyone maintain a comprehensive list of APT group labels that get used? mandia- damnit
|
|
#
?
Mar 19, 2021 21:37
|
|
|
https://cookieconsentspeed.run
|
|
#
?
Mar 19, 2021 21:42
|
|
|
Sassafras posted:but seriously, I've always leaned on https://www.fireeye.com/current-threats/apt-groups.html those cowards don't attribute any of them to the us
|
|
#
?
Mar 19, 2021 22:03
|
|
|
this game doesn't appear to honor the Do Not Track header
|
|
#
?
Mar 19, 2021 22:09
|
|
|
I couldn't beat level 2
|
|
#
?
Mar 19, 2021 23:16
|
|
|
https://twitter.com/_markel___/status/1373059797155778562 is this bad
|
|
#
?
Mar 20, 2021 01:35
|
|
|
i don’t have any idea what “red unlocked” state is, but it’s probably something you need to be running as the kernel to do, which means it’s more a funny hardware trick than a security risk. but if there’s a way to get around that then it’s probably a total protection bypass
|
|
#
?
Mar 20, 2021 01:47
|
|
|
loving with microarchitectural state is probably a great way to lock your processor up, though
|
|
#
?
Mar 20, 2021 01:49
|
|
|
rjmccall posted:loving with microarchitectural state is probably a great way to lock your processor up, though im gonna overwrite all the microcode with D3ADBEEF
|
|
#
?
Mar 20, 2021 01:53
|
|
|
rjmccall posted:loving with microarchitectural state is probably a great way to lock your processor up, though so its an effective attack
|
|
#
?
Mar 20, 2021 01:56
|
|
|
rjmccall posted:i don’t have any idea what “red unlocked” state is, but it’s probably something you need to be running as the kernel to do, which means it’s more a funny hardware trick than a security risk. but if there’s a way to get around that then it’s probably a total protection bypass 
|
|
#
?
Mar 20, 2021 02:03
|
|
|
rjmccall posted:i don’t have any idea what “red unlocked” state is, but it’s probably something you need to be running as the kernel to do, which means it’s more a funny hardware trick than a security risk. but if there’s a way to get around that then it’s probably a total protection bypass presumably it is stricter than that because full micro-architectural state implies the ability to mess with encrypted memory and virtualization
|
|
#
?
Mar 20, 2021 02:39
|
|
|
pseudorandom name posted:presumably it is stricter than that because full micro-architectural state implies the ability to mess with encrypted memory and virtualization Would this allow persistence at the microcode level?
|
|
#
?
Mar 20, 2021 02:53
|
|
|
Unlikely since I'm pretty sure regular microcode patches still need to be reapplied during early boot, there's no persistence there. If you were doing anything in secure enclaves and expecting it to remain immune to tampering from the host system, though, then you may want to reconsider that.
|
|
#
?
Mar 20, 2021 03:29
|
|
|
pseudorandom name posted:presumably it is stricter than that because full micro-architectural state implies the ability to mess with encrypted memory and virtualization that's a good point, although lol @ intel encrypted memory
|
|
#
?
Mar 20, 2021 04:13
|
|
|
Carthag Tuek posted:so its an effective attack i wouldn't expect anything this could do to be set-the-cpu-on-fire levels of bad. it might be halt-the-processor levels of bad, but if you have access to the protection levels that can run this instruction, you can do that already the presentation above is impenetrable; it's just slides full of text referencing things i don't know anything about. maybe one of the hardware folks who hang out here speak intel technology gibberish well enough to say what level of access you're supposed to have to use this thing. but i think it isn't really interesting on a security level unless the protection enforcement on it is unexpectedly weak
|
|
#
?
Mar 20, 2021 04:30
|
|
|
dangit. i was looking forward to the end of cpus 
|
|
#
?
Mar 20, 2021 05:35
|
|
|
Look forward to the End of NFTs instead. A Thread: https://twitter.com/jonty/status/1372163423446917122?s=20 lmao, just lmao at this amazing grift
|
|
#
?
Mar 20, 2021 06:22
|
|
|
As a general rule, if Mark or Maxim posts about something and you have to ask yourself if it's bad, then yes, yes it is.
|
|
#
?
Mar 20, 2021 14:30
|
|
|
lol at censoring the single byte value tho
|
|
#
?
Mar 20, 2021 16:54
|
|
|
rjmccall posted:i wouldn't expect anything this could do to be set-the-cpu-on-fire levels of bad. it might be halt-the-processor levels of bad, but if you have access to the protection levels that can run this instruction, you can do that already Having the ME in Red unlock mode essentially implies full control over the cpu boot vectors and read/write access to physical memory. It means almost everything that could be considered a security boundary is already broken, and means even things like SGX/encrypted memory are compromised. It's supposed to be intel-only but there have been a few documented ways to get vulnerable hardware in the wild into this mode (see: here) in the last few years. This is cool, however, for enabling analysis of microcode updates like reversing out an exhaustive list of what MSRs have actually been added by microcode updates over time. Basically, we might finally see the intel version of this talk that did something similar for older AMD cpus. Decrypting intel microcode updates was already possible, but there was no way to modify them in order to do the sort of differential debugging that enabled the AMD work that was necessary to actually block-box reverse the instruction set.
|
|
#
?
Mar 20, 2021 18:22
|
|
|
yeah, no idea how bad this is for security right at this moment, but for long-term public understanding of cpu security this is surely great.
|
|
#
?
Mar 20, 2021 18:26
|
|
|
having access to architecture state and microcode means you can easily extract all the various ~secret keys~, so even with all the security implications this is a net positive thing
|
|
#
?
Mar 20, 2021 18:43
|
|
|
Truga posted:having access to architecture state and microcode means you can easily extract all the various ~secret keys~, so even with all the security implications this is a net positive thing The group responsible for this new discovery has actually already extracted most of those already thanks to the ME red unlock (also their work). see: https://arstechnica.com/gadgets/2020/10/in-a-first-researchers-extract-secret-key-used-to-encrypt-intel-cpu-code/ and http://blog.ptsecurity.com/2020/03/intelx86-root-of-trust-loss-of-trust.html Looking through their twitter it looks like they found the microcode implementation of these instructions a month ago: https://twitter.com/_markel___/status/1364279711912898561 The new bit is they finally found out what x86 instruction mapped to it. Interestingly it looks like they've already got a pretty decent understanding of the microcode instruction set if they've been disassembling microcoded instruction behaviors. This will certainly make things easier for them though.
|
|
#
?
Mar 20, 2021 18:53
|
|
|
i love how utterly impenetrable this tweet is, and how meaningless the highlighted bit is
|
|
#
?
Mar 20, 2021 23:03
|
|
|
seems like this intel security hole is more of compromising intel encrypted "IP" rather then having any implications for exploiting any running system. but im just a dumb former ee student
|
|
#
?
Mar 20, 2021 23:18
|
|
|
redleader posted:i love how utterly impenetrable this tweet is, and how meaningless the highlighted bit is i think i don't quite understand modern intel microarchitecture well enough for this, but it looks like essentially a microarchitectural longjmp, i.e. it's restoring microarchitecture state from memory and then doing an indirect branch in micro-ops. the weirdest thing is that the branch target is not in microarchitecture state but actually the value in the architectural rax register, implying that the whole thing is actually implementing some (undocumented but still isa-level) instruction to do this. which is presumably one of the instructions he found later
|
|
#
?
Mar 21, 2021 00:25
|
|
|
ate poo poo on live tv posted:seems like this intel security hole is more of compromising intel encrypted "IP" rather then having any implications for exploiting any running system. it isn't a security hole
|
|
#
?
Mar 21, 2021 00:32
|
|
|
It turns out I’m wrong and they’ve had microcode r/w since last year when they managed to dump microcode contents, but they were doing it with hardware debug access to the crbus (also requiring a red mode unlock). What’s new I guess is the ability to self-host this kind of prodding at the microcode without need for a hardware debugger? This is what they had last year: https://twitter.com/h0t_max/status/1316028532972281856, which involved going through the openipc interface, so a platform that had been prepared along the lines of what’s seen here: https://github.com/chip-red-pill/IntelTXE-PoC This team basically managed to knock over ME completely 3 years ago, and they’re 3+ years into taking inventory of just how much access that actually gives them. Intel’s platform has a lot of moving parts.
|
|
#
?
Mar 21, 2021 00:35
|
|
|
just tell me whether this lets me disable the security features that make my CPU slow
|
|
#
?
Mar 21, 2021 01:17
|
|
|
yes, in the sense that security mitigations are controlled by MSRs and the MSRs are a part of the microarchitectural state that you can write but it'd be easier to just write to the MSRs with the WRMSR instruction
|
|
#
?
Mar 21, 2021 01:38
|
|
|
|
| # ? Apr 23, 2024 14:52 |
|
|
https://twitter.com/Esquiring/status/1373409754886864898
|
|
#
?
Mar 21, 2021 02:53
|
|
