Re: [SC-L] Programming language comparison?

[Pete Shanahan]

ljknews wrote:
> At 4:44 PM -0500 2/5/08, Steven M. Christey wrote:
>> On Mon, 4 Feb 2008, ljknews wrote:
>>
 ("%s" to fill up disk or memory, anybody?), so it's marked with
 "All" and it's not in the C-specific view, even though there's a heavy
 concentration of format strings in C/C++.
>>> It is marked as "All" ?
>>>
>>> What is the construct in Ada that has such a risk ?
>> H, I don't see any, but then again I don't know Ada.  Is there no
>> equivalent to format strings in Ada?  No library support for it?
> 
> Not that I know of, but if you can specify a Pascal equivalent
> I might be able to see what you are aiming at.  Have you evaluated
> Pascal for this defect that is present in "All" languages ?
>

Pascal per-se does not have a format string vulnerability - you don't have
any functions like that in the base language.

Delphi (Borland's oo-pascal) however has a whole truckload of Format*
commands which take a format string as the first parameter and thus
would potentially be vulnerable to the DOS attack.

Delphi has the capability of run-time bounds checking, which would catch
a lot of 'variables not on the stack' errors, however this can be turned
off for performance reasons. I don't have a ratio of on/off people. When
I originally wrote Delphi code in '96 I switched off bounds checking as
the systems I was running on could not take the hit. Now, it is left on
continuously as the cost of cycles is not worth it to have better software

___
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
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___

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

[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

[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] Dark Reading - Application and Perimeter Security - Hacking the Vista Kernel - Security News Analysis

[Pete Shanahan]

Hang on a minute,
I thought you had to have administrator access before you were permitted raw
access to the hard drive.

The createfile documentation tells us that opening a physical disk / Volume
requires that the caller must have administrative privileges.

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.

Obviously I need to read more on this.

Kenneth Van Wyk wrote:
> Here's an interesting article from Dark Reading regarding a software
> attack on the existing Vista beta:
> 
> http://www.darkreading.com/document.asp?doc_id=99780&f_src=darkreading_section_296
> 
> 
> I noticed, in particular, that the attack is against a design weakness
> of Vista -- "The attack doesn't use your typical buffer overflow or
> other bug, but basically exploits a Vista (and Windows) design problem
> -- that user-mode applications are allowed to access raw disk sectors,
> Rutkowska says."
> 
> The attack, which is being described in detail at Blackhat, looks for
> "interesting" OS code to be paged out and then carefully modifies the
> contents of the page file in order to dupe Vista into loading the
> corrupt page data.


-- 
Pete+353 (87) 412 9576 [M]
Where there's a will, there's an Inheritance Tax.

___
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

[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 requ

[SC-L] boundaries/responsibilities

[Pete Shanahan]

While I'm riveted by the bug versus flaw debate - as it fundamentally
illustrates the importance of discussing things from the same premise(*), I have
what I would consider to be an interesting tangential issue that has been
bothering me for several years.
I've written many programs (in C, C++) and have never made much effort to make
them input safe. I generally made sure that buffers could not be overrun by
using the 'n' versions of the string functions, and I didn't consider the task
too heavily.
The problem is that my code is in far wider and more varied an environment than
I had ever expected, and I am now concerned that I may be exposed to some form
of liability. This is due to the code having not been issued with any specific
exclusion of warranty; such as would be present in the agreement for the Java
language/environment.


(*) It was my logic lecturer who had an anecdote about two men arguing from
different buildings. A man walks along during one of the arguments and shouts to
the both of them that they will never agree as they are arguing from different
premises.

-- 
Pete+353 (87) 412 9576 [M] | +353 (66) 71 42367 [H]
___
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] [ot] Application Insecurity --- Who is at Fault?

[Pete Shanahan]

Julie JCH Ryan, D.Sc. wrote:
This is a little off topic, but I'm wondering if anyone would like to
comment.
I'll bite, but as I'm not American, you'll have to take my comments with a 
grain
of salt.
Firstly, chastise your student for using the word factoid, it's a fact, a
factoid is untrue. I know this is pedantic, but the harassment I got from my
compiler lecturer about the differences between brackets, braces and parentheses
kind of stuck to me. [ eats, shoots, and leaves ]
The supposition that students have lost their edge is because they do not enter
programming competitions is a poor argument - probably over 20 of the
universities listed in the 76 entries on this year's competition were American,
which seems to be a reasonable percentage, considering that significantly less
than that are of western European origin, I'd say that you've got good odds. I
am aware that this is just throwing some arbitrary statistics at the posting for
this year's results. [ lies, damned lies and statistics ]
The challenge is not in the programming, it's in the problem solving, and the
fact that less American students are winning it should be addressed by
questioning the motivations of those attending, I know for a fact that if I was
offered the opportunity to go to China to attend a programming competition I
would leap at the chance, knowing full well that I would probably not place very
well, but I'd have a damned fun time there. [ the junket argument ]
I think that the duration of the challenge is fair, and as this is a pseudo
exam-like system, the unavailability of the internet is only fair. Being made to
'memorize' things is not the issue, the students are expected to have a good
grounding in all the topics that are likely to turn up in the competition, and
that by having a team you are expecting that they should be capable of at least
doing some forward research into the likely topics so that they don't get caught
short.
Real world programming is for the most part boring - I can count on one hand the
times I've used really interesting algorithms in my work; and I've been working
in what would be for a software engineer a really interesting field. Having a
programming competition that emphasizes mathematical style problems makes it a
fun challenge, without the 'math type' problems, then what would we expect to
see? I for one would lament the loss of a true challenge.
As for the 'have the US programmers lost their lead?' I'd have to say yes, they
have, but that's only because they're now a smaller piece of a much larger pie.
--
Pete +353 (87) 412 9576 [M] | +353 (1) 235 4027 [H]
Boston, n.:
Ludwig van Beethoven being jeered by 50,000 sports fans for
finishing second in the Irish jig competition.