- Joined
- Jan 14, 2008
- Messages
- 9,218
- Reaction score
- 1,566
- Points
- 203
- Location
- VA
- Website
- alteaaerospace.com
- Preferred Pronouns
- he/him
Anyway, i tried it under Wine (after taking a look with IDA - as expected, there is no funny business in there) with patched kernel, and it appears to work just fine.
Well, I'm afraid you are wrong... there is funny business in there .
Nah, the whole business is not funny, it's plain beautiful.the funny business is the whole point. :lol::lol:
For those interested, this here is a windows build of the Spectre example code: https://snoopie.at/face/beta/Spectre.exe . I've added inputs to enter address and length of dump. Default is the location of the secret string like shown in the video above (the content is a different one, though).
After I ran your program, Windows Defender flagged another executable in the same directory as WannaCrypt. :blink:
That Spectre example from the paper uses a buffer overflow technique to read out arbitrary memory addresses in its own virtual memory space with that page cache method. I don't know what effect reading some ranges might have, so it could well be that AV gets irritated.
What ranges did you dump?
So antivirus software might not be as entirely useless as previously claimed.
Where? I don't see a buffer overflow in the paper's sample.
Ah, I see. No AV is able to find that out though, so it shouldn't be triggering anything even if speculative execution tries to read from invalid memory.In the victim function. Of course the classical overflow is prohibited by a conditional jump, but that's the whole point of the exploit. The victim function gets used to train the branch predictor into thinking the x value is always in the range. Then it attacks it by means of giving the malicious x value that is overflowing the buffer. The predictor loads the array addressing part of the victim function into the pipeline, causing pages to get cached. Of course the results are scrubbed due to the x value being out of range, but the read value already can be determined by measuring which page is in cache now.
Yes and no. There are many ways to carry out the attack, and there are many actual legitimate uses of the functionality used in any one Spectre implementation.Wouldn't an antivirus software be able to detect a file with Spectre attack, once the file becomes known to the company?
There are extensions that block specific bad JS scripts, for example: https://chrome.google.com/webstore/...s-on-t/gojamcfopckidlocpkbelmpjcgmbgjcl?hl=en. There are Spectre-specific countermeasures being embedded in browsers, so you probably don't need to install anything.But what about JavaScript? Is there an "antivirus for JavaScript"?
Intel's PR machine has been doing a good job at conflating Meltdown (more serious and is only on Intel CPUs) and SPECTRE (applies to virtually all modern CPUs but is much harder to exploit and can't be patched via the OS) into a "single issue" to make it look like the KPTI patch will affect AMD performance, too, but the Meltdown (KPTI) patch does not need to be applied to AMD CPUs (see this Linux commit from AMD).
That Spectre example from the paper uses a buffer overflow technique to read out arbitrary memory addresses in its own virtual memory space with that page cache method. I don't know what effect reading some ranges might have, so it could well be that AV gets irritated.
What ranges did you dump?
So antivirus software might not be as entirely useless as previously claimed.
Nope. The beauty of it is that there is nothing detectable going on - it will appear simply as a process that is getting an awful lot of exceptions, which is not by itself suspicious.I'm wondering why an OS (or 3rd party antimalware program) can't just flag and/or kill processes that excessively try to read protected memory. The OS has that sort of info, doesn't it?