Re: [SC-L] Could I use Java or c#? [was: Re: re-writingcollege books]

2006-11-15 Thread Pete Shanahan
ljknews wrote:
 At 8:18 PM -0600 11/14/06, Wall, Kevin wrote:
 
 That makes a Java
 inappropriate
 for a lot of system-level programming tasks. Simple example: There's no
 way
 in pure Java that I can lock a process in memory. Wrt this list, that
 has
 a lot of security ramifications especially on shared processors. Sure
 makes
 hiding secrets a lot harder.

It's an operating system feature where you can lock a chunk of the memory of a
process such that it is not swapped out at any time.

see the specs for mlock, madvise.

win32, I believe has an even more feature ridden facility for secure memory.

on the receipt of abnormal termination signals this memory can be cleared, thus
keeping the secret safe, so you could produce a process crash dump that is
sanitized for sending to a support group.

-- 
Pete+353 (87) 412 9576 [M]
I'm gliding over a NUCLEAR WASTE DUMP near ATLANTA, Georgia!!

___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php


Re: [SC-L] Dark Reading - Application and Perimeter Security - Hacking the Vista Kernel - Security News Analysis

2006-07-26 Thread Pete Shanahan
Ken Buchanan wrote:
 I thought you had to have administrator access before you were

 If you took Joanna to mean 'User privileges' when she said
 'user-mode', then you were mistaken.  The opposite of user mode is
 kernel mode.

Yes, I think that would be my foot-in-mouth there. I misread the article,
misinterpreting privileges when it meant non-kernel mode.

 
 I'm just wondering how flawed the implementation of the windows paging
 model is
 that it would allow for this kind of breach. The standard model I'm
 familiar
 with would simply flush the page from memory, and would not keep a
 copy in the
 external page-file, instead relying on the copy that already exists on
 the disk.
 
 Can you explain this objection a little better?  I understand Joanna's
 attack to imply that she is  forcing OS code to be paged out of
 memory, meaning it is now on disk and no longer in physical memory.
 She modifies the paged-out code using raw disk writes, since
 sector-level access bypasses the file system's access control
 protection.  Then, when the OS code is needed again, it is paged back
 into physical memory carrying a whatever little Easter Egg Joanna
 cared to hide in it.

Again, a slight silliness on my behalf - I was thinking that the modifications
were being made to the content of the page-file and not the binary on-disk, as
mentioned in the article:

  This isn't simple for hackers to execute, however. For the attack to succeed,
  one needs to find a reliable way to force interesting kernel code to be paged
  out, then find that code inside a page file and modify it. And finally, the
  kernel needs to load that code (now modified) again into physical memory and
  execute it, she says. The proof-of-concept code I implemented solves all
  those challenges allowing for very reliable exploitation.

I presume the flaw with the OS is that the code signing check only occurs once,
at driver load time, rather than every time any part of it gets paged in.

I've seen malicious cache page corruption on Solaris, where you corrupt a page
that is already loaded in memory, which does not require root access to work.

-- 
Pete+353 (87) 412 9576 [M]
The first time, it's a KLUDGE!
The second, a trick.
Later, it's a well-established technique!

-- Mike Broido, Intermetrics

___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php


Re: [SC-L] Resource limitation

2006-07-18 Thread Pete Shanahan
[EMAIL PROTECTED] wrote:
 I was recently looking at some code to do regular expression matching,
 when it occurred to me that one can produce fairly small regular
 expressions that require huge amounts of space and time.  There's
 nothing in the slightest bit illegal about such regexp's - it's just
 inherent in regular expressions that such things exist.
 

Been there, done that, watched computers go down again and again from this.

 Or consider file compression formats.  Someone out there has a hand-
 constructed zip file that corresponds to a file with more bytes than
 there are particles in the universe.  Again, perfectly legal as it
 stands.
 
 Back in the old days, when users ran programs in their own processes and
 operating systems actually bothered to have a model of resource usage
 that they enforced, you could at least ensure that the user could only
 hurt himself if handed such an object.  These days, OS's tend to ignore
 resource issues - memory and time are, for most legitimate purposes,
 too cheap to meter - and in any case this has long moved outside of
 their visibility:  Clients are attaching to multi-thread servers, and
 all the OS sees is the aggregate demand.
 

Most typical unix/linux environments contain aggregate resource meters - per
process limitations on resource usage.

 Allocating huge amounts of memory in almost any multi-threaded app is
 likely to cause problems.  Yes, the thread asking for the memory will
 die - but unless the code is written very defensively, it stands a
 good chance of bring down other threads, or the whole application,
 along with it:  Memory is a global resource.

Ah, now this would be due to the standard definition of a thread. If you used
something more akin to light weight processes then you could isolate this
resource consumption problem a little bit better.

A thread is the basic unit of processing, it was never intended to be a unit of
resource consumption.

 
 We recently hardened a network protocol against this kind of problem.
 You could transfer arbitrary-sized strings over the link.  A string
 was sent as a 4-byte length in bytes, followed by the actual data.
 A request for 4 GB would fail quickly, breaking the connection.  But
 a request for 2 GB might well succeed, starving the rest of the
 application.  Worse, the API supports groups of requests - e.g.,
 arguments to a function.  Even though the individual requests might
 look reasonable, the sum of them could crash the application.  This
 makes the hardened code more complex:  You can't just limit the
 size of an individual request, you have to limit the total amount
 of memory allocated in multiple requests.  Also, because in general
 you don't know what the total will be ahead of time, you end up
 having to be conservative, so that if a request gets right up close
 to the limit, you won't cause the application problems.  (This, of
 course, could cause the application *other* problems.)
 

Yes, and this falls into general application design. Most network protocols are
designed around the concept of front loading information into the stack. Every
level puts more information at the front, not at the end.
This means that you can make decisions based on a very small piece of data,
allowing you to quickly process it, or kill it should it causes you problems.

If you're allowing such huge data packets and you haven't got the back-end
system in place to process them quickly, and without resource starvation, then
you're just looking to shoot yourself in the foot.

Every system on the planet has had to deal with these problems. From fork-bombs
through to excess network connections. A lot of them can be prevented using
resource limits. Depending on the OS, you can limit resource usage by either
individual process, or group of processes (typically referred to as a 
task-group).

Should an operating system not provide you with integrated features to protect
you from these resource consumptions, then you can quite easily create
monitoring tools that are integrated into the application to monitor and prevent
these kinds of things.
Under an OS like Solaris, you could use a facility like dtrace to monitor
resource use from both the application and OS level to make resource allocation
decisions. This facility would not need to be integrated into the application.

the problem is that a lot of the resource decisions that are made with
applications are more dependent on the administrator rather than the application
developer. After all, while an application developer may say '10% of physical
memory left is OK', and administrator might say 'but what about that other
service there that needs 15%'.

 Is anyone aware of any efforts to control these kinds of vulnerabili-
 ties?  It's something that cries out for automation:  Getting it right
 by hand is way too hard.  Traditional techniques - strong typing,
 unavoidable checking of array bounds and such - may be required for a
 more sophisticated approach, but