The Boston Diaries

The ongoing saga of a programmer who doesn't live in Boston, nor does he even like Boston, but yet named his weblog/journal “The Boston Diaries.”

Go figure.

Thursday, April 26, 2007

Rethinking computer security

I came across this Google Tech Talk about computer security given by Rik Farrow wherein his thesis is that we need to rethink what we're trying to accomplish.

One thought struck me during the discussion on buffer overflow attacks—the Motorola 6809 had two stack pointers, one used by the CPU itself to store return addresses, but another one that I always assumed was supposed to be used solely for parameter passing. So instead of passing parameters on the default stack like, say, the 8086:

MSG.1	DB	'%s',0
MSG.2	DB	'Hello world',13,10,0

	...

	MOV	AX,OFFSET MSG.1
	PUSH	AX		; save on SP
	MOV	AX,OFFSET MSG.2
	PUSH	AX		; save on SP
	CALL	_printf		; return address also on SP

where everything gets pushed onto one stack and you run the risk of overwriting the return address, on the 6809, use the other stack for parameters:

MSG.1	FCS	'%s',0
MSG.2	FCS	'Hello world',13,10,0


	...

	LDX	#MSG.2
	PSHU	X	* push onto the User stack
	LDX	#MSG.1
	PSHU	X	* push onto the User stack
	JSR	_printf	* return address on System stack

Using a separate stack means you only overwrite program data, not critical system information (especially important when arrays are defined on the stack). But, in reading about some of the ways that buffer overwrites can be exploited, this may not foil every attack. But it's a start, and modern CPUs certainly have enough registers to have a separate parameter stack (although in reading interviews with the 6809 designers, it seems the user stack register was meant to construct stack frames on a single stack, much like the x86's use of the SP and BP registers).

That also reminded me of the Intel 432, which treated everything as an object with set memory limits, so gaining a buffer overwrite exploit on a 432-based system would be exceedingly difficult indeed (too bad it died—it's an interesting chip).

But the basic thrust of the talk was that our computer security models are severely outdated and come from a time when a single computer was shared among several people, whereas today, we have a single user shared among computers (or at the very least, a single user per system, and in this talk, he considered something like Apache as a user) using software (say, certain email clients) that accepts code from Lord knows where (say, evil spammers) and simply executes it (because it goes out of its way to press execute the oh so shiny button code). We need to rethink what we want from computer security.

Obligatory Picture

[The future's so bright, I gotta wear shades]

Obligatory Contact Info

Obligatory Feeds

Obligatory Links

Obligatory Miscellaneous

You have my permission to link freely to any entry here. Go ahead, I won't bite. I promise.

The dates are the permanent links to that day's entries (or entry, if there is only one entry). The titles are the permanent links to that entry only. The format for the links are simple: Start with the base link for this site: https://boston.conman.org/, then add the date you are interested in, say 2000/08/01, so that would make the final URL:

https://boston.conman.org/2000/08/01

You can also specify the entire month by leaving off the day portion. You can even select an arbitrary portion of time.

You may also note subtle shading of the links and that's intentional: the “closer” the link is (relative to the page) the “brighter” it appears. It's an experiment in using color shading to denote the distance a link is from here. If you don't notice it, don't worry; it's not all that important.

It is assumed that every brand name, slogan, corporate name, symbol, design element, et cetera mentioned in these pages is a protected and/or trademarked entity, the sole property of its owner(s), and acknowledgement of this status is implied.

Copyright © 1999-2024 by Sean Conner. All Rights Reserved.