The terminal solution to unchecked buffers

The terminal solution to unchecked buffers

Post by Michael Ti » Fri, 15 Aug 2003 19:28:31



C wrote:

Oh yeah... I see... won't bite... :-)


But not with two bytes.


Could you please point me to one of these kinds of attacks that
worked outside of a lab, i.e. made it into a piece of malware that
actually spread?


Two years from now, future hardware will be current hardware.


No without restricting existing legitimate applications.


Yes, but people like to play computer games! I remember days where
it was not unusual to on-the-fly compile some critical inner loop
code onto the stack and execute it there. Used to be the
politically correct alternative to self-modifying-code.


Yes but it is the way it is and cannot be changed easily (see above)


AFAIR, since Windows is sharing code sections between processes,
these ARE read only (via page protection)


Funny, I was suggesting that in a different post. Especially since
it seems easy to implement, like 5 lines of code in CreateThread or
one of its parent functions.


A kernel mode driver is a kernel mode driver and any protection
that is implementted at that level only can serve bug checking, not
much more.


See above.


I was proposing a solution that realistically may be implemented
with what's there. Should-have's describe problems, they don't
solve problems.


Older ones still would be immune, because JMP ESP would not work
the way the attacker intended. Crashing systems don't spread
malware.


Is this assessment backed up by actual knowledge or just a
guesstimate, like mine?


Thanks for the suggestion!


Best regards,

Michael Tippach

 
 
 

The terminal solution to unchecked buffers

Post by Michael Ti » Sat, 16 Aug 2003 17:44:52


The complete paragraph reads (emphasis by me):

----------------------- 8< -------------------------
By appending a large number of bytes to the end of this packet, whilst
preparing the string for the registry key to open, a stack based buffer
is
overflowed and the saved return address is overwritten. This allows an
attacker to gain complete control of the SQL Server process and its path
of
execution. By overwriting the saved return address on the stack WITH AN
ADDRESS THAT CONTAINS A "JMP ESP" OR "CALL ESP" INSTRUCTION, when the
vulnerable procedure returns the processor will start executing code of
the
attacker's choice. At no stage does the attacker need to authenticate.
----------------------- 8< -------------------------

I think that, given my original suggestion, and the notion that
call esp on non- bugged CPUs decrements ESP first, this does not
qualify. It is just one more example of how much exploits depend on
JMP ESP. What if there was no JMP ESP?

Best regards,

Michael Tippach

 
 
 

The terminal solution to unchecked buffers

Post by Korotkov I » Sat, 16 Aug 2003 21:54:01

> The Slammer worm.

Isn't it that worm that spread over the whole world one day in this January
and caused 5 of 13 greatest DNSs to fail?

Ivan
 
 
 

The terminal solution to unchecked buffers

Post by blackmarli » Mon, 18 Aug 2003 04:40:43

ichael Tippach < XXXX@XXXXX.COM > wrote in message news:< XXXX@XXXXX.COM >...

I do not blame you; somethime I just cannot resit blasting an
easy target :-)


PUSH ESP ;; 54
RET ;; C3

(and they do not even have to be next to each other, plus they
are both frequently used in normal software)

[Note: though this method works on current processors it does
not work on older (8086) processors --- to quote the Intel P4
manual (2) 3-642 "The PUSH ESP instruction pushes the value of
the ESP register as it existed before the instruction was
executed."]


Others have done so (unfortunatly I do not have access to my
library of virus source code at the moment so I cannot add to
these examples.)


I am currently writing this on a Pentium 120 machine - many of
us do not have the money to upgrade every two years.


Restricting yes, though there is nothing to stop the user
disabling the protection for one application while retaining
the protections for other appications which are written with
the new API in mind.


That is why I mention (futher down) the necessity of providing an
executable heap for programmes using a JIT scheme - there is little
difference between an executable heap and an executable stack.
Besides, there is nothing to stop one application (eg. a game)
having an executable stack while another (eg. a mail client) does
not.


The only reason stopping Intel adding this change is a lack of
free bits in the page table entries - maybe by prividing a MSR
to enable it and using one of the 'avail' bits (9-11) this
could be achieved -- though, utilising selectors, this feature
is not really needed. Afterwards it is just a matter of linking
the TLB read only page fault signal to the L1 (code) cache page
request signal via the new bit -- therefore #PF is generated on
an attempt to execute protected code.

'Oliver S.' stated the AA-64 has added such functionality; I
will have to look into this architecture.


They probably are. That was not my point, which was to allow
the possibility of JIT compilers, which would need a writable
heap execute code on.


Yup :-)


You are correct, this paragraph mainly refered to microkernels
or applications - it is (as you state) not applicable to kernel
mode drivers.


Yes, though many of the above solutions I proposed my be retro
fitted into current operating system implementations.


No, because older ones would not enable the proposed 'block JMP ESP'
flag.


Educated guess : my reasoning is that JMP ESP is sufficiently
primitive (RISC like) to be implemented directly in hardware
and if not the microcode for JMP ESP is probably lumped
together with all the (useful) JMP <reg> instruction formats.