Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #67601 > unrolled thread

Re: How security holes happen

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: How security holes happen Cameron Simpson <cs@zip.com.au> - 2014-03-04 09:19 +1100
    Re: How security holes happen Roy Smith <roy@panix.com> - 2014-03-03 18:05 -0500
      Re: How security holes happen Chris Angelico <rosuav@gmail.com> - 2014-03-04 10:36 +1100
    Re: How security holes happen Andrew Cooper <root@127.0.0.1> - 2014-03-05 00:52 +0000
      Re: How security holes happen Gene Heskett <gheskett@wdtv.com> - 2014-03-04 23:27 -0500
      Re: How security holes happen 88888 Dihedral <dihedral88888@gmail.com> - 2014-03-05 18:39 -0800

#67601 — Re: How security holes happen

On 03Mar2014 09:17, Neal Becker <ndbecker2@gmail.com> wrote:
>  Charles R Harris <charlesr.harris@gmail.com> Wrote in message:
> > 
> 
> Imo the lesson here is never write in low level c. Use modern
>  languages with well designed exception handling.

What, and rely on someone else's low level C?
-- 
Cameron Simpson <cs@zip.com.au>

Hag:                    Two things you must know about the wise woman.
                        First...she is a woman.  Second...she is...
Edmund Blackadder:      Wise?
Hag:                    Oh! You know her then?
Edmund Blackadder:      No, just a stab in the dark, which is what you'll be
                        getting in a minute if you don't become more helpful.
       - Edmund Blackadder to Old Hag, Bells, BA2

[toc] | [next] | [standalone]

#67615

In article <mailman.7670.1393885170.18130.python-list@python.org>,
 Cameron Simpson <cs@zip.com.au> wrote:

> On 03Mar2014 09:17, Neal Becker <ndbecker2@gmail.com> wrote:
> >  Charles R Harris <charlesr.harris@gmail.com> Wrote in message:
> > > 
> > 
> > Imo the lesson here is never write in low level c. Use modern
> >  languages with well designed exception handling.
> 
> What, and rely on someone else's low level C?

Don't laugh.  http://c2.com/cgi/wiki?TheKenThompsonHack

[toc] | [prev] | [next] | [standalone]

#67617

On Tue, Mar 4, 2014 at 10:05 AM, Roy Smith <roy@panix.com> wrote:
> In article <mailman.7670.1393885170.18130.python-list@python.org>,
>  Cameron Simpson <cs@zip.com.au> wrote:
>
>> On 03Mar2014 09:17, Neal Becker <ndbecker2@gmail.com> wrote:
>> >  Charles R Harris <charlesr.harris@gmail.com> Wrote in message:
>> > >
>> >
>> > Imo the lesson here is never write in low level c. Use modern
>> >  languages with well designed exception handling.
>>
>> What, and rely on someone else's low level C?
>
> Don't laugh.  http://c2.com/cgi/wiki?TheKenThompsonHack

I don't think malicious interference with C compilers is the issue
here, so much as the constant discovery of flaws in honestly-written C
code.

Currently, I'm porting a MUD client from C++ to Pike. On average, a
hunk of code shrinks by about 50% during the translation, mainly
because I can let memory management happen elsewhere. (Sometimes the
difference is even more dramatic. I wrote my own binary tree in the
C++ client, because the compiler I was targeting at the time didn't
provide a suitable mapping type; now, I just call on the language's
facilities, and it's more efficient and takes no code whatsoever.
That's basically one entire module eliminated.) Along the way, I'm
noticing myriad little issues around the place, where too much data
would result in something being truncated (I was careful in most
places to ensure that it couldn't blow the stack, although I certainly
wouldn't bet money that I was perfect on that score), and the
truncation could have unexpected results. Malformed data coming in
over a TCP socket would eventually consume all the buffer space and
then make the client think the other end had closed its connection.
That one I knew about and didn't care, but there were others that were
weird and esoteric and would *most likely* never happen.

Writing low level code opens you up to a huge collection of weird
behaviours that might, at best, become bug reports that you spend
hours trying to solve. At worst, they become exploits. Yes, high level
languages have their own attack vectors, but I'd much rather have the
entire python-dev team working to solve my problems than me alone :)

ChrisA

[toc] | [prev] | [next] | [standalone]

#67771

On 03/03/2014 22:19, Cameron Simpson wrote:
> On 03Mar2014 09:17, Neal Becker <ndbecker2@gmail.com> wrote:
>>  Charles R Harris <charlesr.harris@gmail.com> Wrote in message:
>>>
>>
>> Imo the lesson here is never write in low level c. Use modern
>>  languages with well designed exception handling.
> 
> What, and rely on someone else's low level C?
> 

Why is C the lowest denominator?

Even with correctly written C and assembly, how can you be sure that
your processor is executing the SYSRET instruction safely?
(CVE-2012-0217 for anyone interested)

~Andrew

[toc] | [prev] | [next] | [standalone]

#67797

On Tuesday 04 March 2014 23:17:40 Andrew Cooper did opine:

> On 03/03/2014 22:19, Cameron Simpson wrote:
> > On 03Mar2014 09:17, Neal Becker <ndbecker2@gmail.com> wrote:
> >>  Charles R Harris <charlesr.harris@gmail.com> Wrote in message:
> >> Imo the lesson here is never write in low level c. Use modern
> >> 
> >>  languages with well designed exception handling.
> > 
> > What, and rely on someone else's low level C?
> 
> Why is C the lowest denominator?
> 
> Even with correctly written C and assembly, how can you be sure that
> your processor is executing the SYSRET instruction safely?
> (CVE-2012-0217 for anyone interested)
> 
If you do not have the system tools to determine that, the system is 
seriously incomplete.  Change os's, its that simple when you are down to 
the bare metal.

If I wanted to determine that was correct on the TRS-80 Color Computer 3 in 
the basement, running nitros9 right now, I would put 3 calls to F$RegDump 
in the assembly code, one in the caller as the last thing done before the 
call, one in the subroutine immediately in front of the return, and one as 
the first operation done when the return register image has been pulled 
from the stack.

> ~Andrew


Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

NOTICE: Will pay 100 USD for an HP-4815A defective but
complete probe assembly.

[toc] | [prev] | [next] | [standalone]

#67911

On Wednesday, March 5, 2014 8:52:31 AM UTC+8, Andrew Cooper wrote:
> On 03/03/2014 22:19, Cameron Simpson wrote:
> 
> > On 03Mar2014 09:17, Neal Becker <ndbecker2@gmail.com> wrote:
> 
> >>  Charles R Harris <charlesr.harris@gmail.com> Wrote in message:
> 
> >>>
> 
> >>
> 
> >> Imo the lesson here is never write in low level c. Use modern
> 
> >>  languages with well designed exception handling.
> 
> > 
> 
> > What, and rely on someone else's low level C?
> 
> > 
> 
> 
> 
> Why is C the lowest denominator?
> 
> 
> 
> Even with correctly written C and assembly, how can you be sure that
> 
> your processor is executing the SYSRET instruction safely?
> 
> (CVE-2012-0217 for anyone interested)
> 
> 
> 
> ~Andrew

It is not  difficult to write C with
mixed assembly codes for different
CPUs. 

#ifdef ASM  
/* asm follows */
....

#ifdef CPUTYPES 
/* insert CPU ASMS for different 
CPUs carefully here */

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web