Re: Privilege-escalation attacks on NT-based Windows are unfixable

From: Edward Elliott (nobody@127.0.0.1)
Date: 08/29/02 

From: Edward Elliott <nobody@127.0.0.1>
Date: Thu, 29 Aug 2002 20:33:56 GMT

On Thu, 29 Aug 2002 05:33:49 -0400, Benjamin Goldberg wrote:
> The ability to execute untrusted code in a sandbox.
>
> Code signing, to allow one to automatically give code that came from a
> trusted author greater permissions than code from untrusted authors.

These are both features which protect users that run untrusted code.
They have nothing to do with helping that code resist attacks. It's a
different threat model from what I'm considering.

> The ability to mark a string as having originated from outside the
> program, and die if an unsafe (system, exec, etc) operation is
> performed with it. Oops, no, that's perl with taint checking. :)

I wish more languages had taint checking.
 
> PS: Within perl, bounds checking on strings is enforced; bounds
> checking on arrays is sorta enforced (arrays are automatically
> extended); perl has no raw pointers; perl has a lock() keyword for
> thread safety; And there's no undefined behavior since perl's "proper"
> behavior is defined by the implementation. Ok, that last one is a
> negative, not a positive, but all the other points match. And perl6
> has no undefined behavior, afaik.

So it falls somewhere between C and Java on the scale.
 
>> Let's also make a list of what attacks these features mitigate, and
>> to what degree:
>>
>> 1. Buffer overflows (completely, barring VM bugs) 2. Internal race
>> conditions (somewhat, synchronized must be used properly)
>
> In the Perl programming language, there's no buffer overflows, barring
> implementation bugs in the perl binary.

Right. There are no overflows because the language runtime prevents
them (barring implementation bugs). Same as Java. That's why it's on
the list.

> Nor race conditions...

Huh? You're saying the perl runtime alone prevents all race
conditions? I know that's not true; external race conditions (on
files, sockets, etc) _can't_ be prevented without explicit checks by
the programmer. Are you saying it's true for internal perl program
resources (scalars, hashes, arrays, refs, etc)? 

-- 
Edward Elliott

Relevant Pages

  • Re: Privilege-escalation attacks on NT-based Windows are unfixable
    ... > The ability to execute untrusted code in a sandbox. ... These are both features which protect users that run untrusted code. ... Oops, no, that's perl with taint checking. ... > In the Perl programming language, there's no buffer overflows, barring ...
    (comp.os.ms-windows.nt.admin.security)
  • Re: Strong Blog CGI in Perl
    ... Or, more precisely, the some I've seen in Perl doesn't ... show the usual features like list of recent comments, ... build a blog with these features? ... Ability to fine tune the theme ...
    (comp.lang.perl.misc)
  • Re: Help me get "Directory" out of full windows path name?
    ... Random Task wrote: ... it seems like you are fairly new to Perl programming. ... I would recommend purchasing ...
    (comp.lang.perl.misc)
  • Re: graphics in perl
    ... We are running perl 5.8.5 on a Linux machine that is running apache 2.2.6 ... Our data is in a MySQL database ... ability to create histograms ...
    (perl.beginners)
  • Re: graphics in perl
    ... We are running perl 5.8.5 on a Linux machine that is running apache 2.2.6 ... Our data is in a MySQL database ... ability to create histograms ...
    (perl.beginners)