Log in

View Full Version : Hardware-based read-only memory

disavowed
January 11th, 2004, 19:38
It will be interesting to see how this technology will be used to hinder reverse-engineering:

http://news.com.com/2100-7355_3-5137832.html ("http://news.com.com/2100-7355_3-5137832.html")
evn
January 12th, 2004, 03:21
From the Article:
Quote:

A number of damaging worms from last year relied on buffer overflows. Around 50 percent of the Windows security updates from Microsoft in the last two years may have been rendered unnecessary if the technology existed then, according to an analysis by AMD and Microsoft.


I don't know about anyone else, but i find it irresponsible for a software company (or programmer) to write code that relies on the underlying systems security to function as securely as possible. Just because the CPU can prevent attack doesn't mean that everybody is using that CPU, or an operating system that takes advantage of it.

I don't think that technology like this will (or can) be used as a reverse-engineering hindrance at the moment, due to the nature of the technology and the current state of difference between computer systems worldwide. To use the technology would require the company to target a specific hardware and software configuration, which commercial companies often cannot (or won't) support due to complications with other hardware or software (very important in fields of animation and media, CGI, etc.).

The article doesn't really tell much about the hardware except that it read-only's the buffer memory. If the hardware was changed to read-only the entire application, packers and self-modifying code would become unusable and would (probably) leave the software less protected than it originally was.

CPU emulation software (such as VMWare) could always be used to bypass it on systems that support the technology, which i'm sure would be done.
elfz
January 12th, 2004, 08:31
Hmm, of course that's nice how marketing presents this ("will prevent buffer overflows, blah blah blah". The thing changing is that i386 page protection don't have "read, but don't execute" kind of flag. Now, starting with XP SP2 on supported platforms (currently currently AMD K8, Itanium, and AMD64) stack and heap won't be executable anymore (until you call VirtualProtectEx of course).

Sure enough, some of the protections will die because of this.

http://msdn.microsoft.com/library/en-us/dnwxp/html/securityinxpsp2.asp
Mr. Blue
January 12th, 2004, 10:44
OpenBSD and Linux (a patch should be applied) currently have the ability to disable code execution on the stack without any hardware-specific changes. So I guess this new feature is not as simple as a new memory protection bit. Unfortunately the article doesn't give any technical details
elfz
January 12th, 2004, 12:56
From the information found on the net, it seems that really, that is only NX flag for the memory page, that means "No eXecution".
A little more information can be found on The Register http://www.theregister.co.uk/content/4/33729.html but there's much junk information too.
disavowed
January 12th, 2004, 19:03
Quote:
[Originally Posted by elfz]Hmm, of course that's nice how marketing presents this ("will prevent buffer overflows, blah blah blah".

yes, especially because it won't prevent buffer overflows. it will prevent exploitation (arbitrary code execution) by means of buffer overflows. however, i would expect buffer overflows could still be used to crash the process (denial of service)
doug
January 12th, 2004, 21:57
Quote:

however, i would expect buffer overflows could still be used to crash the process (denial of service)


yes in fact, one of the article mentionned this.
It would crash the process, but it would no longer replicate itself... yielding a much smaller (and slower) distribution of the worm.