The Return Oriented Programming Hackers

happygeek 0 Tallied Votes 664 Views Share

Want to know how to fix an election without resorting to bribery and corruption? Ever thought about throwing some Return Oriented Programming into the voting equation?

Ordinarily, the hacking into of an electronic voting machine might spark a little bit of interest if there were an election looming perhaps. That said, the potential insecurity of such machines can happily be filed under old news.

However, my attention was grabbed by the paper (Can DREs Provide Long-Lasting Security?) from a bunch of security researchers based at the Universities of California, Michigan and also Princeton. Not least because while it did, I admit, involve revealing how a Direct Recording Electronic voting machine had been hacked it also described something called Return Oriented Programming. Also, much of the research that has gone before when it comes to the security of voting machines tends to rely greatly upon having access to source code. The researchers say that they hope their results "go some way towards answering the objection, frequently raised by vendors, that voting security researchers enjoy unrealistic access to the systems they study."

The DRE voting machine in question, a Sequoia AVC Advantage, dates back to the 80's so maybe it is not that surprising that it can be hacked today. However, that does not make it an easy target: the thing employs numerous safeguards such as separating data and code, and throwing up a non-maskable interrupt error if someone were to try and execute injected code in RAM (the actual executable code for this machine is held in ROM). Nor does it make the research irrelevant, as the team states in its paper "because the development, certification, and procurement cycle for voting machines is unusually slow, the service lifetime can be twenty or thirty years."

Yet the research team are insistent, courtesy of Return Oriented Programming techniques, that if someone used the same techniques as they describe it would be possible, assuming they had access to the machine in the first place, to replace the installed election application with one of their own which could manipulate the voting in any way the attacker wished.

"The Z80 instruction set is very dense. Every byte is either a valid opcode or is a prefix byte. As there are no invalid or privileged instructions, instruction decoding of any sequence of data always succeeds" the researchers explain in their paper, adding "This density facilitates return-oriented programming since we can exploit unintended instruction sequences to build gadgets — a sequence of pointers to instruction sequences ending with a ret." By using a stack that is made up of code snippet addresses the researchers were able to show how they can recreate what are, for all intents and purposes, arbitrary programs. It's clever stuff, using a bog standard buffer overflow within the program code to create the stack and having a ret instruction triggering one ret after another in order to execute the vote rigging code itself.

The team have managed to demonstrate that an attacker could exploit vulnerabilities in one particular voting machine in order to install vote-stealing malware using a maliciously formatted memory cartridge. The important thing being that they have done this without replacing the system ROMs and starting out with "no source code, schematics, or nonpublic documentation." The whole attack-stealing code was produced in less than 16 man-months of labour and at a cost, if replicated in the private sector of around $100,000.

Kudos to Stephen Checkoway, J. Alex Halderman, Ariel J. Feldman, Edward W. Felten, Brian Kantor and Hovav Shacham for their innovative research.

Dani AI

Generated

This thread correctly flags return-oriented programming (ROP) as a milestone that changed how defenders think about memory protections: ROP is a code-reuse technique that can produce arbitrary behavior by stitching together short instruction sequences already present in memory. For background and the canonical research that launched the field, see the ROP literature. (hovav.net)

Practical, developer-facing mitigations are well understood and effective when applied in layers. At build time, enable compiler hardening (stack canaries / -fstack-protector-strong, -fstack-clash-protection, FORTIFY_SOURCE and full RELRO/PIE). At run time, ensure DEP/NX and ASLR are enabled and use platform CFI/CFG where available. Where hardware supports it, enable CPU-level protections such as Intel CET (shadow stacks + indirect-branch tracking). These measures together raise the bar against gadget-chaining attacks. (gcc.gnu.org)

For legacy or embedded systems (the class of devices discussed earlier in the thread), modern OS/hardware features may be absent — compensating controls become critical: cryptographically signed firmware and updates, immutable or write-protected boot images, strict physical-port lockdown, minimal trusted code base, audit logging, and independent third‑party testing against standards such as the EAC VVSG. Platform firmware resiliency and measured boot practices (TPM/attestation, recovery paths) are recommended for devices that must remain in service for many years. (eac.gov)

Actionable short checklist: add sanitizers and fuzzing to CI (AddressSanitizer, UBSan), turn on compiler and linker hardening flags for production builds, enable OS/firmware mitigations on supported hardware, require signed updates and maintain an auditable fallback/restore mechanism, and plan independent code review and post-deployment auditing. For deeper reading on defenses and compiler-based approaches see the survey and G-Free work on gadget elimination. The platform-specific points raised by are important: hardening must be validated per-target, not assumed. (rocm.docs.amd.com)

traskdigital -2 Newbie Poster

Hi dear,
We are know the mother language of computer.And we can generate system as well as application programming.OOPs is a big concept language of orinted program.C language is used for hacking program by hackers.

Talking about buffer overflow exploit on x86, Mac OS X is the most easy and hacker friendly target compare to Linux or Windows. OS X always loads /usr/lib/dyld at a fixed location and it contains a lot of helper stubs to launch the exploit.

MosaicFuneral 812 Nearly a Posting Virtuoso

We are know the mother language of computer.And we can generate system as well as application programming.OOPs is a big concept language of orinted program.C language is used for hacking program by hackers.

I'm still trying to decipher this paragraph. You or no collective can be a "know" or a "mother language".

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.