Re: Why write an Ada web browser ?, was: Re: GNAT Ada - DLL - MSVC

[clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley)]

In article <3D0761FF.38554417@sympatico.ca>, David Marceau <davidmarceau@sympatico.ca> writes:
> Simon Clubley wrote:
>> 
>> So, my question is, why write a whole new web browser in Ada ?
> So the browser would be more reliable, more secure and more easily
> maintained/reused.
> Note how I didn't say it would be faster than assembler or c.
> 

I agree about it not needing to be faster than the _same_ program written
in C. I would even accept it been a little slower. However, I would like
to think that a properly designed Ada browser would need less resources
than some of today's browsers.

>> 
>> Some advantages are obvious; an Ada browser shouldn't have problems with
>> buffer overflows.
> Buffer overflows have been seen as security issues in os's.  

In this case, the buffer overflow is not in the operating system, but
in the browser. The idea is that an attacker can construct a malformed
response to a request from the browser that causes the browser's stack to
be overwritten because of a buffer overflow. Buffer overflow attacks have
been usually carried out against web servers, but browsers can be vulnerable.
See for example:

http://www.microsoft.com/technet/security/bulletin/MS02-027.asp

> Ada helps to minimize this.  Unless you are deliberately using pointers
> in your software,
> Ada has a much stronger chance at not doing any buffer overflow.

Agreed.

>> 
>> However, I don't see how an Ada based browser would help with other
>> errors like cross-site scripting which I understand are mainly logic
>> errors.
> What do you mean by cross-site scripting?
> 

Cross-site scripting is where an attacker can get a script to execute
within a more trusted local zone within the browser. This is normally an
attack used with the help of a web server, but a web browser itself can be
targetted.

A cross-site scripting tutorial that I found while typing this response is at:

http://support.microsoft.com/default.aspx?scid=kb;EN-US;q252985

and here's an example of it targetting IE itself:

http://www.microsoft.com/technet/security/bulletin/MS02-023.asp

Another variant is a frame based scripting attack, see:

http://www.microsoft.com/technet/security/bulletin/MS02-009.asp

You may argue that the cross-site scripting attacks are not the kind of
thing that Ada could be reasonably expected to stop. However, in that case,
the fact that the browser is written in Ada would probably make no difference.

Regardless of the above, I would argue that a frame based attack _is_ a
logic error, and I don't see how an Ada browser would stop that kind of
logic error from occuring just because it's written in Ada.

>> 
>>         Would you write a Java Virtual Machine implementation in Ada ?
> In my opinion it is a waste of time because assuming you have access to
> the source, you could recompile on any platform quite easily.
> The recompiled ada would be much faster than a JVM running java byte
> code.  JAVA and jvm is hype IMHO.
> 

You may have misunderstood me here. I am talking about the Ada web browser
needing to run a Java applet located on the site that the user is visiting.
In order to do this, the browser needs to have a JVM built into it. The
question is, do you use an existing JVM, or do you write a new JVM in Ada ?

>> 
>>         How about FTP/Telnet/secure sockets, etc ?
> Sockets. Don't have to Adasockets
> Secure sockets. Don't have to Adasockets
> Http downloads/uploads binary files. Don't have to AWS.
> FTP seems to be redundant now. No.
> Telnet yes.  Great for debugging.
> gdb yes.
> ssh/ssl.   Yes and by far the most important for security reasons.
> 

I don't see how gdb fits in.

FTP is not redundant. The question is, would it be worth it to re-implement
things like Telnet and FTP in Ada ?

BTW, I didn't realise that Adasockets had SSL. I will have to have a look...

>> 
>> What method would an Ada browser use to handle the requirement to
>> dynamically support plug-in modules and to execute the code within
>> that plug-in ? What would be the advantages of that method ?
> Dynamic run-time plug-ins are a security issue.
> Making an architecture that permits dynamic loaded plug-ins that can
> access the same piece of memory in a process is a hackers paradise.
> (i.e. .so's/.dll's)
> That's why having source is better.  You can decide to save disk
> space(using .dll's/.so's) or not(using static .a's).
> For security reasons, I prefer to think source and building the .a
> myself is best.

Here, you seem to be suggesting that if a user wants to run a new plug-in
that a third party has developed, or for a protocol that may have not have
existed when the browser was created, then the user should download
the source code and recompile the web browser.

If so, such an approach would make sure that an Ada web browser would never
be in general use (IMHO), unless it offered major advantages to the end user.

Assuming that dynamic plug-ins are required, is there anything that Ada
can teach us about a more secure way to implement the architecture ?

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP       
Microsoft: The Lada of the computing world.