http://www.smashguard.org

[Hilmi Ozdoganoglu]

SmashGuard is a hardware-based solution developed at Purdue
University to prevent Buffer-Overflow Attacks realized by overwriting the
Function Return Address (patent-pending). The design of SmashGuard is a
kernel patch that supports CPUs modified to support SmashGuard protection.

For details please refer to the TechReports at:

http://www.smashguard.org

In addition to details of SmashGuard, the site serves as a comprehensive
resource for buffer overflow attacks/prevention/detection. On "the buffer
overflow page" we provide links to research papers, known exploits, safer
C languages, patents, audit tools and more. If you can think of a site or
resource that should be added please send email to our webmaster
(cyprian@purdue.edu)

-SmashGuard Group

[Dave Paris]

I'm not sure I understand the economics involved here. Taking the
worst-case (software) cited at an 8.3% performance hit, this says a 3.2GHz
P4 will give approximately the same performance as a 2.9GHz machine. Or put
another way, for every 12 machines I have operating on a problem (say, in a
cluster of some sort), I have to add in one additional machine to make up
for the performance hit. If we're talking about commodity, x86 server type
hardware, we're not talking about a lot of money, even if you factor in the
additional costs for another switch port, etc. Certainly not the kind of
money one would expect to be kicking around for custom CPUs - which I would
guess to be _well_ in excess of SPARC or PA-RISC prices.

I think the project/product is quite interesting from an academic
standpoint, but unless it can be put into mainstream production with
existing vendors, my realistic side says it'll never be economically
feasible to get out of academia.

Kind Regards,
-dsp

-----Original Message-----
From: Hilmi Ozdoganoglu [mailto:cyprian@purdue.edu]
Sent: Friday, January 30, 2004 6:34 PM
To: bugtraq@securityfocus.com
Subject: http://www.smashguard.org



SmashGuard is a hardware-based solution developed at Purdue
University to prevent Buffer-Overflow Attacks realized by overwriting the
Function Return Address (patent-pending). The design of SmashGuard is a
kernel patch that supports CPUs modified to support SmashGuard protection.

For details please refer to the TechReports at:

http://www.smashguard.org

In addition to details of SmashGuard, the site serves as a comprehensive
resource for buffer overflow attacks/prevention/detection. On "the buffer
overflow page" we provide links to research papers, known exploits, safer
C languages, patents, audit tools and more. If you can think of a site or
resource that should be added please send email to our webmaster
(cyprian@purdue.edu)

-SmashGuard Group

[Nicholas Weaver]

On Tue, Feb 03, 2004 at 07:36:55AM -0500, Dave Paris composed:
> I'm not sure I understand the economics involved here. Taking the
> worst-case (software) cited at an 8.3% performance hit, this says a 3.2GHz
> P4 will give approximately the same performance as a 2.9GHz machine. Or put
> another way, for every 12 machines I have operating on a problem (say, in a
> cluster of some sort), I have to add in one additional machine to make up
> for the performance hit. If we're talking about commodity, x86 server type
> hardware, we're not talking about a lot of money, even if you factor in the
> additional costs for another switch port, etc. Certainly not the kind of
> money one would expect to be kicking around for custom CPUs - which I would
> guess to be _well_ in excess of SPARC or PA-RISC prices.

Especially since StackGuard/ProPolice/GC flags are now growing
widespread (on by default in current/future M$ products, on-by-default
in OpenBSD) and teh overhead in practice is a fair bit lower than the
8% worst case hit.

EG,
http://www.research.ibm.com/trl/projects/security/ssp/node5.html#SECTION00051000000000000000

8% is the WORST CASE overhead for ProPolice: it does a character array
and a function call. IN practice, its a 4% performance overhead for
perl, 1% for ctags, and 0% for imapd. Amdahl's law works in both
directions: you can also slow down infrequent events and have very
little impact on performance.

> I think the project/product is quite interesting from an academic
> standpoint, but unless it can be put into mainstream production with
> existing vendors, my realistic side says it'll never be economically
> feasible to get out of academia.

Speaking as an academic and an architecture type, I'm not even sure if
its all that interesting from an academic viewpoint...

There are lots of changes/studies which can be done in the
architecture field which would offer much more improved performance

(Both of these are projects I'd like to see architecture-class
students do, as I don't have the time...)

EG, what happens for a RISC instruction set, or even better, an
IA64-like ISA, when you have an "Aligned 4/Aligned 8 register"
spill/load instruction. I know this is reasonable from a physical
viewpoint: Wires are cheap, its interconnect (switching) thats
expensive, and with 3+ issue, there are definatly enough wires to the
RF to access 4 or 8 locations in a single cycle, but I don't know the
effect from the compiler viewpoint, or what the overall performance
result would be.

Or what happens if you make a 3 issue IA64: How much slowdown over a
full 6-issue Itanium II do you get in practice? I think this can be
estimated by doing a binary translation to insert stop bits. What
happens if you then interleave-multithread ($C$-slow) it, droping the
single-thread clock by another 10-20%, but now supporting two
independant threads? This might take a simluator.




Or much more improved security/security performance:

Better hardware/software codesegin real-time garbage collection and
runtime bounds checks needed for safe languages. There was a lot of
work done on this in the 80s, what happens if it gets revisited today,
with much cheaper silicion?

--
Nicholas C. Weaver nweaver@cs.berkeley.edu

[Leon Harris]

Interesting paper.
Certain apps (notably java virtual machines) manipulate stack return
addresses. I understood that one of the advantages of Immunix's product
StackGuard was that you could still run these types of apps by
statically linking them against a normal libc (and chrooting them or
otherwise confining them). If the protection is mandatory, and in
hardware, then surely these types of app wont work.

Cheers,
Leon

Hilmi Ozdoganoglu wrote:

> SmashGuard is a hardware-based solution developed at Purdue
>University to prevent Buffer-Overflow Attacks realized by overwriting the
>Function Return Address (patent-pending). The design of SmashGuard is a
>kernel patch that supports CPUs modified to support SmashGuard protection.
>
> For details please refer to the TechReports at:
>
> http://www.smashguard.org
>
> In addition to details of SmashGuard, the site serves as a comprehensive
>resource for buffer overflow attacks/prevention/detection. On "the buffer
>overflow page" we provide links to research papers, known exploits, safer
>C languages, patents, audit tools and more. If you can think of a site or
>resource that should be added please send email to our webmaster
>(cyprian@purdue.edu)
>
>-SmashGuard Group
>

[Seth Arnold]

--0OAP2g/MAC+5xKAE
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Feb 04, 2004 at 01:26:29PM +0800, Leon Harris wrote:
> Certain apps (notably java virtual machines) manipulate stack return=20
> addresses. I understood that one of the advantages of Immunix's product=
=20
> StackGuard was that you could still run these types of apps by=20
> statically linking them against a normal libc (and chrooting them or=20
> otherwise confining them). If the protection is mandatory, and in=20
> hardware, then surely these types of app wont work.

Leon, the limitations with StackGuard and Java Just in Time compilers
and virtual machines have been removed with newer versions of
StackGuard. StackGuard 2, based on egcs (gcc 2.91.66), had an unfortunate
location in the stack layout for the canary which caused problems for
applications that 'knew' the stack layout well enough to introspect
the stack.

Newer versions of StackGuard have since remedied the location of the
canary (to be more secure, while we're at it) such that applications that
are stack-introspective no longer need to be patched to know a 'new'
stack layout. StackGuard 3 uses a better location that is transparent
to gdb, mozilla, JITs, etc.

Of course, I don't want to say what forms of applications may or may not
run on a SmashGuard system; however, the JVMs and JITs may or may not
function on SmashGuard on their own merits -- it was a limitation of
earlier StackGuard releases that caused problems for JVMs, JITs, gdb,
mozilla, etc.

Further information on StackGuard 3 may be found at:
http://immunix.org/stackguard.html

More information will be posted to this page as StackGuard continues
development, and we will periodically announce new developments to the
low traffic immunix-announce mail list:
http://mail.immunix.com/mailman/listinfo/immunix-announce

Thanks Leon

--=20
Immunix Secured Linux Distribution: http://immunix.org/

--0OAP2g/MAC+5xKAE
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFAIoYL+9nuM9mwoJkRAtEkAJ9+676qDN79Y2UviHKaN2 ac0M18RgCePOp9
WbqBMqqWh8s4kDutdhqiEek=
=MgR+
-----END PGP SIGNATURE-----

--0OAP2g/MAC+5xKAE--

[Hilmi Ozdoganoglu]

Agreed, the software based approach does not take a significant
performance hit, but the hardware approach is transparent to the user
and does not require recompilation of the source code. Therefore, all
programs can run securely on a machine whether or not they are "compiled
securely" (e.g. legacy software).

The idea is not to create "custom CPUs" but to have our modification
picked up by major vendors. Clearly there is interest in applying
hardware to solve security issues based on the latest press releases
from AMD that AMD chips include buffer-overflow protection (see
Computer World, January 15, 2004).

--The SmashGuard Group



On Tue, 3 Feb 2004, Dave Paris wrote:

.... I'm not sure I understand the economics involved here. Taking the
.... worst-case (software) cited at an 8.3% performance hit, this says a 3.2GHz
.... P4 will give approximately the same performance as a 2.9GHz machine. Or put
.... another way, for every 12 machines I have operating on a problem (say, in a
.... cluster of some sort), I have to add in one additional machine to make up
.... for the performance hit. If we're talking about commodity, x86 server type
.... hardware, we're not talking about a lot of money, even if you factor in the
.... additional costs for another switch port, etc. Certainly not the kind of
.... money one would expect to be kicking around for custom CPUs - which I would
.... guess to be _well_ in excess of SPARC or PA-RISC prices.
....
.... I think the project/product is quite interesting from an academic
.... standpoint, but unless it can be put into mainstream production with
.... existing vendors, my realistic side says it'll never be economically
.... feasible to get out of academia.
....
.... Kind Regards,
.... -dsp
....
.... -----Original Message-----
.... From: Hilmi Ozdoganoglu [mailto:cyprian@purdue.edu]
.... Sent: Friday, January 30, 2004 6:34 PM
.... To: bugtraq@securityfocus.com
.... Subject: http://www.smashguard.org
....
....
....
.... SmashGuard is a hardware-based solution developed at Purdue
.... University to prevent Buffer-Overflow Attacks realized by overwriting the
.... Function Return Address (patent-pending). The design of SmashGuard is a
.... kernel patch that supports CPUs modified to support SmashGuard protection.
....
.... For details please refer to the TechReports at:
....
.... http://www.smashguard.org
....
.... In addition to details of SmashGuard, the site serves as a comprehensive
.... resource for buffer overflow attacks/prevention/detection. On "the buffer
.... overflow page" we provide links to research papers, known exploits, safer
.... C languages, patents, audit tools and more. If you can think of a site or
.... resource that should be added please send email to our webmaster
.... (cyprian@purdue.edu)
....
.... -SmashGuard Group
....
....
....
....
....

[Theo de Raadt]

> The idea is not to create "custom CPUs" but to have our modification
> picked up by major vendors.

Er..

> Clearly there is interest in applying
> hardware to solve security issues based on the latest press releases
> from AMD that AMD chips include buffer-overflow protection (see
> Computer World, January 15, 2004).

Whoa, hold on. What these vendors are doing to their cpus is not on
the same scale as what you are suggesting.

In this regard, all AMD has added (to the amd64) is a per-page
non-executable bit. In PAE mode, bit 63 of the PTE becomes a NX bit.

This is not really all that new. sparc v8, sparc v9, alpha, and hppa
have had this for a very long time. The motorola 88k is also capable
of this, due to the split mmu handling. In general cpus like mips,
vax, m68k, and powerpc cpus are not capable of it. Some cpus with
split code & data tlb's are -- if they have software tlb load
mechanisms -- and some arm cpus fall into this catagory. But
performance can suffer significantly if the mechanims are poorly
designed.

Some operating systems make use of this. Such as OpenBSD, for ..
what.. 2 years now..

Now why is this not the same as yours? Even though we have an entire
operating system modified to operate with as many non-executable page
as possible, we still consider this a weaker protection mechanism than
gcc propolice. However these two very cheap mechanisms can work
together to improve resistance; fewer bugs can be exploited to control
flow.

By the way, I am pleased to say that my research has shown that the
AMD PAE NX bit will work in 32 bit mode. We are trying to make
modifications that will permit OpenBSD to use it.

[Nicholas Weaver]

On Fri, Feb 06, 2004 at 03:29:30PM -0500, Hilmi Ozdoganoglu composed:
>
> Agreed, the software based approach does not take a significant
> performance hit, but the hardware approach is transparent to the user
> and does not require recompilation of the source code. Therefore, all
> programs can run securely on a machine whether or not they are "compiled
> securely" (e.g. legacy software).

Not all control flow follows stack logic. So you can't claim
backwards compatibility on all programs.

What happens if you are compiling continuations, such as a
high-performance ML or scheme environment?

A scheme environment may often need to keep around call-stacks after
they are exited, because call-with-current-continuation can cause them
to be reentered again.

Similarly, you mention the problem with user-land threads, yet
specifically don't solve it (just handwave it a bit).

Likewise, what happens on table-blowout? You are using fixed-sized
tables, what happens when they fill up (and they WILL fill up.
Resources in a CPU should be 0, 1, or infinite, at least from the
user's point of view).

--
Nicholas C. Weaver nweaver@cs.berkeley.edu

[Crispin Cowan]

Hilmi Ozdoganoglu wrote:

> Agreed, the software based approach does not take a significant
>performance hit, but the hardware approach is transparent to the user
>and does not require recompilation of the source code. Therefore, all
>programs can run securely on a machine whether or not they are "compiled
>securely" (e.g. legacy software).
>
Utter nonsense. Legacy software has to be recompiled to use the new CPU
instruction set. A new CPU architecture is vastly *more* intrusive than
a new compiler.

>The idea is not to create "custom CPUs" but to have our modification
>picked up by major vendors. Clearly there is interest in applying
>hardware to solve security issues based on the latest press releases
>from AMD that AMD chips include buffer-overflow protection (see
>Computer World, January 15, 2004).
>
As Theo said, the AMD buffer overflow "protection" is nothing more than
sensible separation of R and X bits per page, fixing a glaring and
anomalous defect in the original 386 MMU. Many CPUs before and since had
this feature, and it was just Intel slop in the early 1980s that
developed an MMU (and associated instruction set) that mistakenly
treated R and X per page as one bit.

Crispin

--
Crispin Cowan, Ph.D. http://immunix.com/~crispin/
CTO, Immunix http://immunix.com
Immunix 7.3 http://www.immunix.com/shop/