Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
https://git.kernel.org/…/ke…/... sure some of you are working on the patches already, if you are then lets connect cause, I am an ardent researcher for the same as of now.
So here it goes:
As soon as kernel page table isolation(KPTI) bug will be out of embargo, Whatsapp and FB will be flooded with over-night kernel "shikhuritee" experts who will share shitty advices non-stop.
1. The bug under embargo is a side channel attack, which exploits the fact that Intel chips come with speculative execution without proper isolation between user pages and kernel pages. Therefore, with careful scheduling and timing attack will reveal some information from kernel pages, while the code is running in user mode.
In easy terms, if you have a VPS, another person with VPS on same physical server may read memory being used by your VPS, which will result in unwanted data leakage. To make the matter worse, a malicious JS from innocent looking webpage might be (might be, because JS does not provide language constructs for such fine grained control; atleast none that I know as of now) able to read kernel pages, and pawn you real hard, real bad.
2. The bug comes from too much reliance on Tomasulo's algorithm for out-of-order instruction scheduling. It is not yet clear whether the bug can be fixed with a microcode update (and if not, Intel has to fix this in silicon itself). As far as I can dig, there is nothing that hints that this bug is fixable in microcode, which makes the matter much worse. Also according to my understanding a microcode update will be too trivial to fix this kind of a hardware bug.
3. A software-only remedy is possible, and that is being implemented by all major OSs (including our lovely Linux) in kernel space. The patch forces Translation Lookaside Buffer to flush if a context switch happens during a syscall (this is what I understand as of now). The benchmarks are suggesting that slowdown will be somewhere between 5%(best case)-30%(worst case).
4. Regarding point 3, syscalls don't matter much. Only thing that matters is how many times syscalls are called. For example, if you are using read() or write() on 8MB buffers, you won't have too much slowdown; but if you are calling same syscalls once per byte, a heavy performance penalty is guaranteed. All processes are which are I/O heavy are going to suffer (hostings and databases are two common examples).
5. The patch can be disabled in Linux by passing argument to kernel during boot; however it is not advised for pretty much obvious reasons.
6. For gamers: this is not going to affect games (because those are not I/O heavy)
Meltdown: "Meltdown" targeted on desktop chips can read kernel memory from L1D cache, Intel is only affected with this variant. Works on only Intel.
Spectre: Spectre is a hardware vulnerability with implementations of branch prediction that affects modern microprocessors with speculative execution, by allowing malicious processes access to the contents of other programs mapped memory. Works on all chips including Intel/ARM/AMD.
For updates refer the kernel tree: https://git.kernel.org/…/ke…/...
For further details and more chit-chats refer: https://lwn.net/SubscriberLink/...
~Cheers~
(Originally written by Adhokshaj Mishra, edited by me. )
22 -
A group of Security researchers has officially fucked hardware-level Intel botnet officially branded as "Intel Management Engine" they did so by gathering it all the autism they were able to get from StackOverflow mods... though they officially call it a Buffer Overflow.
On Wednesday, in a presentation at Black Hat Europe, Positive Technologies security researchers Mark Ermolov and Maxim Goryachy plan to explain the firmware flaws they found in Intel Management Engine 11, along with a warning that vendor patches for the vulnerability may not be enough.
Two weeks ago, the pair received thanks from Intel for working with the company to disclose the bugs responsibility. At the time, Chipzilla published 10 vulnerability notices affecting its Management Engine (ME), Server Platform Services (SPS), and Trusted Execution Engine (TXE).
The Intel Management Engine, which resides in the Platform Controller Hub, is a coprocessor that powers the company's vPro administrative features across a variety of chip families. It has its own OS, MINIX 3, a Unix-like operating system that runs at a level below the kernel of the device's main operating system.
It's a computer designed to monitor your computer. In that position, it has access to most of the processes and data on the main CPU. For admins, it can be useful for managing fleets of PCs; it's equally appealing to hackers for what Positive Technologies has dubbed "God mode."
The flaws cited by Intel could let an attacker run arbitrary code on affected hardware that wouldn't be visible to the user or the main operating system. Fears of such an attack led Chipzilla to implement an off switch, to comply with the NSA-developed IT security program called HAP.
But having identified this switch earlier this year, Ermolov and Goryachy contend it fails to protect against the bugs identified in three of the ten disclosures: CVE-2017-5705, CVE-2017-5706, and CVE-2017-5707.
The duo say they found a locally exploitable stack buffer overflow that allows the execution of unsigned code on any device with Intel ME 11, even if the device is turned off or protected by security software.
For more of the complete story go here:
https://blackhat.com/eu-17/...
https://theregister.co.uk/2017/12/...
I post mostly daily news, commentaries and such on my site for anyone that wish to drop by there
19 -
Forgive me father, for I have sinned. Alot actually, but I'm here for technical sins. Okay, a particular series of technical sins. Sit your ass back down padre, you signed up for this shit. Where was I? Right, it has been 11429 days since my last confession. May this serve as equal parts rant, confession, and record for the poor SOB who comes after me.
Ended up in a job where everything was done manually or controlled by rickety Access "apps". Many manhours were wasted on sitting and waiting for the main system to spit out a query download so it could be parsed by hand or loaded into one of the aforementioned apps that had a nasty habit of locking up the aged hardware that we were allowed. Updates to the system were done through and awful utility that tended to cut out silently, fail loudly and randomly, or post data horrifically wrong.
Fuck that noise. Floated the idea of automating downloads and uploads to bossman. This is where I learned that the main system had no SQL socket by default, but the vendor managing the system could provide one for an obscene amount of money. There was no buy in from above, not worth the price.
Automated it anyway. Main system had a free form entry field, ostensibly for handwriting SELECT queries. Using Python, AutoHotkey, and glorified copy-pasting, it worked after a fashion. Showed the time saved by not having to do downloads manually. Got us the buy in we needed, bigwigs get negotiating with the vendor, told to start developing something based on some docs from the vendor. Keep the hacky solution running as team loves not having to waste time on downloads.
Found SQLi vulnerability in the above free form query system, brought it up to bossman to bring up the chain. Vulnerability still there months later. Test using it for automated updates. Works and is magnitudes more stable than update utility. Bring it up again and show the time we can save exploiting it. Decision made to use it while it exists, saves more time. Team happier, able to actual develop solutions uninterrupted now. Using Python, AutoHotkey, glorified copy-pasting, and SQLi in the course of day to day business critical work. Ugliest hacky thing I've ever caused to exist.
Flash forward 6 years. Automation system now in heavy use acrossed two companies. Handles all automatic downloads for several departments, 1 million+ discrete updates daily with alot of room for expansion, stuff runs 24/7 on schedule, most former Access apps now gone and written sanely and managed by the automation system. Its on real hardware with real databases and security behind it.
It is still using AutoHotkey, copy-paste, and SQLi to interface with the main system. There never was and never will be a SQL socket. Keep this hellbeast I've spawned chugging along.
I've pointed out how many ways this can all go pearshaped. I've pointed out that one day the vendor will get their shit together they'll come in post system update and nothing will work anymore. I've pointed out the danger in continuing to use the system with such a glaring SQLi vulnerability.
Noone cares. Won't be my problem soon enough.
In no particular order:
Fuck management for not fighting for a good system interface
Fuck the vendor for A) not having a SQL socket and B) leaving the SQLi vulnerability there this long
Fuck me for bringing this thing into existence5
Top Tags
Weekly Rant
View