Mail #13192

Back to main page of archive

Previous mail   Next mail   Unformatted/full headers
Overview  10 days   Subject   Date   Thread   Author  

From: Mirsad Todorovac
Subject: Buffer Overrun Prevention in GPC
Date: 30 Jan 2006, 10:41:25

On Sun, 29 Jan 2006, Adriaan van Os wrote:

> Mirsad Todorovac wrote:
>
>> I see. I realize adding security measures drastically impacts performance 
>> (such as making all pointers "volatile" variables which cannot go to 
>> registers), but having an important system brought down on it's knees by 
>> undetected buffer overrun in an application will hurt me more both as a 
>> system administrator and as a software developer than the 20% decrease in 
>> program speed. IMHO.
>
> Back to reality. You are not obliged to build buffer overruns into your 
> software, are you ?

Reality is that I have done so, looking back at the times 10 years ago 
when I was writing CGI programs. Effectivelly, I have opened access to 
shell to an intruder. The fact that it did not happen is pure luck.

(But so did Mr. Brian Kennighan, right? With introducing gets() that 
cannot be protected from overruns he was laying the system's security on 
wrong assumtion. And I deeply respect him and do not think he was stupid 
or incompetent. Simply the users were different at that time, and they 
were behaving.)

I was laying my code on wrong assumptions on safety, extensivelly using 
strcpy(), memcpy() and similar functions that leak the water. I assume 
that novice programmers would do the same (of course, today CGI is mostly 
replaced by PHP and perl "preempted" C for the purpose, but then again 
leaving the possibility to write CGI programs that leak is a bad security 
policy. Disabling them completely is something I do not prefer since we 
are University and that would cripple student's opportunity ot learn. Even 
learn on errors). Then, having instelled a CGI program that has security 
hole without knowing that, I could rely only on obscurity of code to keep 
the attackers away.

Looking at Microsoft policy of obscurity that simply does not work and we 
are brought down to our knees with every new kind of virus I came to think 
something ought to be done on system level. Essentially, using Perl or 
Java would eliminate 95% of buffer overruns implicite.

Of all this talk I will summarize with the fact that programs nowadays are 
written by a larger community than 30 or 40 years ago languages like 
Pascal have been designed. And even experienced programmers are pushed 
with deadlines to implement more and more features on the fly and without 
propper planning and testing.

So, Mr. van Os, I would like Pascal to prevent me from shooting my own 
leg in some very stupid mistakes.

>> Right said: StackGuard does exactly that! I could try to apply StackGuard 
>> patch once GPC would have accepted 4.* backends.
>
> You can do that right now already, see 
> <http://www.gnu-pascal.de/crystal/gpc/en/mail12959.html>.

Thank you, I have read the message and I think that is what I need. Part 
of solution.

I will have to do some research before I reply to Mr. Heckenbach, since I 
relied on lecture from 15 years ago (about heap fragmentation). (And hope 
my network will not be brought down by a new exploit.)

Best regards,
Mirsad

Previous mail   Next mail   Unformatted/full headers
Overview  10 days   Subject   Date   Thread   Author  

Replies

In reply to

Back to main page of archive

Note: This page contains information that does not originate from the owner of this web site, but from the authors of the mails archived. The owner of this web site is not responsible for the content of such information. Any use of that infomation requires the consent of the respective author.

Where WWW addresses (URLs) in the mails archived are marked as hyperlinks, this is only for the comfort of the reader. The content of the web pages linked to like this does not necessarily reflect the opinion of the owner of this web site or of the authors of the mails archived. The owner of this web site is not responsible for the content of such web pages. Those pages are explicitly not to be considered as part of the content of this page, but merely as references.

This page was created by Crystal 0.999 (Linux 2.4.27/i686).