Web browser in Ada

Web browser in Ada

[Gautier write-only]

There are discussions from time to time, since very long, about
writing a Web browser in Ada.
The main idea would have a safe browser.
Actually today's issues about security in Web browsers remarkably seem
of the same kind as ten years ago, just a bit more frequent and acute.
Did someone give a try ?
I guess the following libraries would be considered:
- AWS, for the HTTP requests
- GtKAda, for a portable GUI
- the least possible bindings and the most possible Ada code for
decoding images and other contents
_________________________________________________________
Gautier's Ada programming -- http://sf.net/users/gdemont/
NB: For a direct answer, e-mail address on the following web site:
http://www.fechtenafz.ethz.ch/wm_email.htm

Re: Web browser in Ada

[Maciej Sobczak]

On 23 Kwi, 10:03, Gautier write-only <gautier_niou...@hotmail.com>
wrote:

> The main idea would have a safe browser.

From what I understand, the vulnerabilities in todays browsers are
related to plugins or dependent libraries, which are all natively
executed.

Writing a web browser in Ada that would not have those plugins (you
are not going to reimplement them, I believe) would be - as far as
security is concerned - equivalent to a reasonable existing browser
with all plugins disabled.

Am I missing something?

Could you refer to an existing browser vulnerability that is related
to the core browser engine and that would be avoided by choosing
another language?
(I'm genuinely interested)

--
Maciej Sobczak * http://www.inspirel.com

YAMI4 - Messaging Solution for Distributed Systems
http://www.inspirel.com/yami4

Re: Web browser in Ada

[Georg Bauhaus]

On 23.04.10 15:56, Maciej Sobczak wrote:

> 
> Could you refer to an existing browser vulnerability that is related
> to the core browser engine and that would be avoided by choosing
> another language?
> (I'm genuinely interested)


Does CSS count? Or image rendering components?
"buffer overflow" + {ie6, mozilla, ...} produce a number of
search results.  Then there is the presence of DEP in recent
MS systems brough to your desktop with IE7 ...

Buffer overflow continues to rank high, e.g. in the 2010 SANS Top 25:
http://cwe.mitre.org/data/definitions/120.html

Integer overflow or wraparound and improper array indexing rank
somewhat lower, but are present, too.

BTW, why do we still subscribe to the notion "integer overflow"
when the one thing that any sequence of what is commonly known
as integers cannot possibly do is to overflow?  Maybe the
wording is at the heart of the problem.

I think it is adequate and pedagogical to call it "int overflow".

Re: Web browser in Ada

[Martin Krischik]

Am 23.04.2010, 16:37 Uhr, schrieb Georg Bauhaus  
<rm.dash-bauhaus@futureapps.de>:

> On 23.04.10 15:56, Maciej Sobczak wrote:

> BTW, why do we still subscribe to the notion "integer overflow"
> when the one thing that any sequence of what is commonly known
> as integers cannot possibly do is to overflow?  Maybe the
> wording is at the heart of the problem.

Not at all. This is an integer overflow:

int dayOfMonth =  32;

Simplified example of course.

Martin
-- 
Martin Krischik

Re: Web browser in Ada

[Georg Bauhaus]

On 27.04.10 13:41, Martin Krischik wrote:
> Am 23.04.2010, 16:37 Uhr, schrieb Georg Bauhaus
> <rm.dash-bauhaus@futureapps.de>:
> 
>> On 23.04.10 15:56, Maciej Sobczak wrote:
> 
>> BTW, why do we still subscribe to the notion "integer overflow"
>> when the one thing that any sequence of what is commonly known
>> as integers cannot possibly do is to overflow?  Maybe the
>> wording is at the heart of the problem.
> 
> Not at all. This is an integer overflow:
> 
> int dayOfMonth =  32;

I don't think that this is an integer overflow
by the common definition of "integer overflow" (which
relies on "int", not implications of the name "dayOfMonth"
---and also not on "integer").  No overflow there,
just a terrible programming mistake.
In Ada, other than predefined "Integer" and such, there are no
named integer types.  Good thing, as this lack suggests
adding at least range constraints, if not new types.
In C, many programmers seem to think there are integers
and that their name is "int".

(On a 5bit architecture one could even be mislead to
believe that the above declaration would create overflow
(disregarding the logical error), since 32 > 2^5 - 1.
But I think that C's minimum requirement for an "int"
is storing values between -(2^15 - 1) and +(2^15 - 1)---
whatever width the underlying hardware's words do
actually have.)

So the above would "flow over" the range constraint of a
suitably defined Month subtype in Ada.  (Forgetting about
February problems for the moment, that can only to be solved
in type systems such as Qi's.)


> Simplified example of course.

Uhm, the heart of the problem is that "int" is taken to mean,
..., well, ... an integer?  Yes, the above is a logical
error, one that could have been prevented mechanically
by using a good base type system, one that does not
include "the integers".  Which is my point: that it is
a misconception to think of "int" as an integer.
If you think of "int" as what it is: "int", and if you are
smart, then little can go wrong.
This is easier to get right once you have a base type system
that naturally suggest not to think in terms of an
infinite set of arbitrary high school numbers, but of
computer entities.  Like Ada's.  I like this characterization
of C's int:

"The int type was typically the most convenient native
data type for integer math." (*)

The "native" part is what seems lost in stereotypical C
knowledge.

(*) http://www.ibm.com/developerworks/power/library/pa-ctypes3/index.html

Re: Web browser in Ada

[AdaMagica]

But Standard.Integer is an integer ;-)

  Very_Big   : constant :=      Integer'Last +      Integer'Last;  --
"+" of Integer
  Even_Bigger: constant := Long_Integer'Last + Long_Integer'Last;  --
"+" of Long_Integer
  Illegal    : constant := Long_Integer'Last +      Integer'Last;  --
"+" mixing

Integer overflow is int overflow (Re: Web browser in Ada)

[Georg Bauhaus]

On 27.04.10 16:00, AdaMagica wrote:
> But Standard.Integer is an integer ;-)
> 
>   Very_Big   : constant :=      Integer'Last +      Integer'Last;  --
> "+" of Integer
>   Even_Bigger: constant := Long_Integer'Last + Long_Integer'Last;  --
> "+" of Long_Integer
>   Illegal    : constant := Long_Integer'Last +      Integer'Last;  --
> "+" mixing

Are these really of type Standard.Integer?  I think (after rummaging
through the RM) they are not.
These are named numbers, and their declaration has no effect.
They are of type universal_integer (unconstrained?) which has no name.
And they cannot overflow then.

The builtin "+" can deliver the sum of any static constants
within capacity constraints of the compiler.

package Big is

   Z : constant := 2 ** 1_000_000_000;

   Y : constant := 2 ** 10_000;

   A : constant := 9 ** (9 ** 9);

   B : constant := Long_Long_Integer'Succ (2**63 - 1);

   Bigger : constant Boolean := B > Long_Long_Integer'Last;

end Big;

Compiling: big.ads (source file time stamp: 2010-04-27 14:53:49)

     5.    Z : constant := 2 ** 1_000_000_000;
                             |
        >>> static value too large, capacity exceeded

     7.    A : constant := 9 ** (9 ** 9);
                             |
        >>> static value too large, capacity exceeded


Unavailable:
  for D'Size use ...;
  pragma Inspection_Point (...);

Big.Bigger is True.

My conclusions would be that:

Standard.Integer is a constrained subtype. Its objects are
not like (what is commonly known as) integers, a set that can
be extended at will.
They cannot overflow in Ada mode.  There is no wrap-around.

Named numbers of no-name type universal_integer
cannot overflow, their value is determined by the compiler,
they are not objects, and they can hit compiler capacity limits.

So neither Standard.Integer nor universal_integer is an integer.

Nor is C's int.  Still assuming C's int is like integers,
encouraged by how "int" and "integer" are used interchangeably
in talks and writings, leads to to overflow (this is my
hypothesis).

Re: Integer overflow is int overflow (Re: Web browser in Ada)

[Dmitry A. Kazakov]

On Tue, 27 Apr 2010 17:30:44 +0200, Georg Bauhaus wrote:

> My conclusions would be that:
> 
> Standard.Integer is a constrained subtype. Its objects are
> not like (what is commonly known as) integers, a set that can
> be extended at will.

The set of integers is not extensible "at will." You probably meant that
for any integer there exists at least one [actually an infinitely countable
set] of greater or lesser integers. Nevertheless the set of integers (Z) is
fixed.

Standard.Integer is not an integer, it is a type, used to model integers or
other entities. It is not Z independently on how adequately it models the
latter.

> They cannot overflow in Ada mode.  There is no wrap-around.

> Named numbers of no-name type universal_integer
> cannot overflow, their value is determined by the compiler,

Their behavior, you mean. The value is determined by the expression and the
language rules.

> they are not objects, and they can hit compiler capacity limits.

Whether they are [run-time] objects is up to compiler. The compiler in Ada
has certain freedom to "objectize" and "deobjectize" things.

> So neither Standard.Integer nor universal_integer is an integer.

See above. They are not per definition. The question how adequately they
can model Z, is answered as: neither does it 100%. The domain of either
type is finite. Both domains include non-integer ideal elements called
"exception propagation" or "compile error." Concerning the latter, for any
legal Ada program there can exist a compiler capable to compile it without
error [if you have enough material and time].

> Nor is C's int.  Still assuming C's int is like integers,
> encouraged by how "int" and "integer" are used interchangeably
> in talks and writings, leads to to overflow (this is my
> hypothesis).

You need overflow in order to define the behavior of the operations closed
only in Z. E.g. "+".

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Integer overflow is int overflow (Re: Web browser in Ada)

[Georg Bauhaus]

On 27.04.10 18:13, Dmitry A. Kazakov wrote:
> On Tue, 27 Apr 2010 17:30:44 +0200, Georg Bauhaus wrote:
> 
>> My conclusions would be that:
>>
>> Standard.Integer is a constrained subtype. Its objects are
>> not like (what is commonly known as) integers, a set that can
>> be extended at will.
> 
> The set of integers is not extensible "at will." You probably meant that
> for any integer there exists at least one [actually an infinitely countable
> set] of greater or lesser integers. Nevertheless the set of integers (Z) is
> fixed.

Thanks for adding clarity. It is much needed.

> The value is determined by the expression and the
> language rules.

(OK, nitpicking, there is no value denoted by a named number
if determination does not actually happen. Words mean
nothing unless they are given meaning. ;-) ;-)

>> they are not objects, and they can hit compiler capacity limits.
> 
> Whether they are [run-time] objects is up to compiler. The compiler in Ada
> has certain freedom to "objectize" and "deobjectize" things.

Thanks, I didn't know this.


> You need overflow in order to define the behavior of the operations closed
> only in Z. E.g. "+".

True if it is not possible to define "+" in terms of saturation
or wrap-around, I think. Correct?

However, programmers do not define "+" in their C programs.
They use "+"!
Then overflow occurs, and not to prove the soundness of the
language definition, but as a mishap.

Re: Integer overflow is int overflow (Re: Web browser in Ada)

[Dmitry A. Kazakov]

On Tue, 27 Apr 2010 19:09:43 +0200, Georg Bauhaus wrote:

> On 27.04.10 18:13, Dmitry A. Kazakov wrote:
> 
>> The value is determined by the expression and the
>> language rules.
> 
> (OK, nitpicking, there is no value denoted by a named number
> if determination does not actually happen. Words mean
> nothing unless they are given meaning. ;-) ;-)

Yes, but the meaning is given by the language rules, not by the running
instance of the compiler. Therefore:

   X : constant := 2**(2**(2**(2**1_000_000_000)));

is well-defined even if there likely will never exist a compiler-machine
combination capable to swallow it.

>> You need overflow in order to define the behavior of the operations closed
>> only in Z. E.g. "+".
> 
> True if it is not possible to define "+" in terms of saturation
> or wrap-around, I think. Correct?

"+" can be defined in any way. The question is the semantics of. If the
semantics of "+" is to model Z, then it cannot return a value from Z which
is mathematically wrong. The problem is not in a singular value. It is with
the programs that will use this value in other computations. In the end it
will break everything about Z. You won't be certain about any evaluated
value. Ideals like exceptions, NaN etc, limit the damage.
 
> However, programmers do not define "+" in their C programs.
> They use "+"!
> Then overflow occurs, and not to prove the soundness of the
> language definition, but as a mishap.

Yes. If the programmer is lucky then the behavior maps the implied
semantics. This is what we call "safe choice." Unfortunately C's choices
are often unsafe in the sense that the layman programmer's expectations are
far not what C actually does.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Web browser in Ada

[Gautier write-only]

> Could you refer to an existing browser vulnerability that is related
> to the core browser engine and that would be avoided by choosing
> another language?
> (I'm genuinely interested)

It is a very good question, that should be solved before jumping into
such a time-consuming project :-).

My impression is that a good part of vulnerabilities are indeed within
plug-ins, another good part is between the browser and a plug-in
(typically, browser X need to be patched but not the others nor the
plug-in), and the third part, important as well, is about CSS,
JavaScript, image storage or decoding, XML, HTML parsing and other
core parts of browsers. I had a glimpse on:
  http://www.mozilla.org/security/known-vulnerabilities/
and a randomly with
  http://www.google.com/search?q=browser+security+update

Hopefully someone more knowledgeable than me can answer your question,
or give percentages to the parts above...

G.

Re: Web browser in Ada

[Peter C. Chapin]

Gautier write-only wrote:

> My impression is that a good part of vulnerabilities are indeed within
> plug-ins, another good part is between the browser and a plug-in
> (typically, browser X need to be patched but not the others nor the
> plug-in), and the third part, important as well, is about CSS,
> JavaScript, image storage or decoding, XML, HTML parsing and other
> core parts of browsers.

I had actually thought that building a web browser in Ada would be a nice
project (if only I had more time!). I'm not sure how much of a difference in
security it would make... probably some.

Any browser that could be realistically used would need to support JavaScript.
While an Ada JavaScript implementation might (or might not) be more secure
than a C implementation, it seems to me that any vulnerability related to the
JavaScript language itself would still be a risk.

In any case, the real benefit of such a project would be more in the
development of associated libraries and supporting code (imagine processing,
HTML parsing and rendering, CSS handling, etc, etc)... and in the visibility
a successful project would give to Ada. I suspect Ada was first standardized
before many current web developers were born; it might be fun to see what
sort of reception an Ada web browser project would get in that community.

Anyway a good first step might be the implementation of an HTML 5 parser in
Ada. Rather than playing catch-up that would put an Ada web browser project
right in the thick of the bleeding edge of the web world.

Peter

Re: Web browser in Ada

[Gautier write-only]

Peter C. Chapin:

> I had actually thought that building a web browser in Ada would be a nice
> project (if only I had more time!). I'm not sure how much of a difference in
> security it would make... probably some.

> Any browser that could be realistically used would need to support JavaScript.
> While an Ada JavaScript implementation might (or might not) be more secure
> than a C implementation, it seems to me that any vulnerability related to the
> JavaScript language itself would still be a risk.

Maybe it is a bit naive, but I have the impression that JavaScript's
vulnerability can be limited to the interaction with the surronding
operating system: file I/O and code execution (this includes starting
a plug-in).

> In any case, the real benefit of such a project would be more in the
> development of associated libraries and supporting code (imagine processing,
> HTML parsing and rendering, CSS handling, etc, etc)...

Sure. For images, I could provide some bits (some of them existing),
even in a generic way (reusable for other projects, GUIs etc.).

> and in the visibility
> a successful project would give to Ada. I suspect Ada was first standardized
> before many current web developers were born; it might be fun to see what
> sort of reception an Ada web browser project would get in that community.

Just remind them that the current browsers are made in a language
their grandparents were already using :-).

> Anyway a good first step might be the implementation of an HTML 5 parser in
> Ada. Rather than playing catch-up that would put an Ada web browser project
> right in the thick of the bleeding edge of the web world.

But probably when there will be something working you will have to
catchup with HTML 8 :-)
Just kidding. It is a very good idea, especially that the W3C
specification gives also hints about the parsing.
G.

Re: Web browser in Ada

[Peter C. Chapin]

Gautier write-only wrote:


> Maybe it is a bit naive, but I have the impression that JavaScript's
> vulnerability can be limited to the interaction with the surronding
> operating system: file I/O and code execution (this includes starting
> a plug-in).

I don't know much about JavaScript at the moment, honestly. It sounds like you
are saying that current insecurities in JavaScript are in its interface to
the rest of the world. If so, a more secure implementation of the language
itself might help (depend on what "more secure implementation" really means,
exactly).

> Just kidding. It is a very good idea, especially that the W3C
> specification gives also hints about the parsing.

Another potential benefit is that the W3C is, as I understand it, currently
looking for implementation feedback on the proposed specification. So the
time seems ripe to think about an HTML 5 implementation.

Peter

Re: Web browser in Ada

[Georg Bauhaus]

On 4/24/10 2:38 AM, Peter C. Chapin wrote:

> Any browser that could be realistically used would need to support JavaScript.
> While an Ada JavaScript implementation might (or might not) be more secure
> than a C implementation, it seems to me that any vulnerability related to the
> JavaScript language itself would still be a risk.

A major flaw in Javascript is how its type system was built,
I think.  (The vulnerabilities being listed in the Top 25
vulnerabilities of 2010.) Being less prejudiced against Ada
(or even Pascal) could have helped with giving Javascript
a robust foundation:

1 - they obviously used (the dark side of) duct tape programming
when wrapping the fundamental types of C, lazily. Perhaps in order
to ship something quickly.
For the C types, chose those available on a given platform...! (IINM)
Looking at the "flexible" phrasing in the Javascript ECMA standard still
makes me sad. BTW, Ruby has the very same problems with its base types.
This problem---it seems to have spread across "scripting"
languages---does not seem to be easy to correct after the fact.

2 - The higher level Javascript stuff looks like it is borrowed
from CLOS.
What does Ada have to offer here? Can it improve a poor man's CLOS
implementation so it becomes better than one built atop a C
implementation?


> In any case, the real benefit of such a project would be more in the
> development of associated libraries and supporting code (imagine processing,
> HTML parsing and rendering, CSS handling, etc, etc)... and in the visibility
> a successful project would give to Ada. I suspect Ada was first standardized
> before many current web developers were born; it might be fun to see what
> sort of reception an Ada web browser project would get in that community.

I think image processing or movie handling could profit. The reason
is that Ada programmers, by stereotype or nature, will think about sizes
and boundary cases.  Speed is near C's as is once again demonstrated
by the Mandelbrot entry in the Shootout.  However, Ada's run-time
systems are not (yet?) supporting multicores that well.  If it
matters.

> Anyway a good first step might be the implementation of an HTML 5 parser in
> Ada.

What is an HTML 5 parser supposed to be?

If it is to parse the SGML text defined by the HTML 5 grammar
then you would, in effect, have to copy browsers' near natural language
processing capabilities, since having only an SGML parser with little
more than moderate error correction capabilities is by far not enough
for HTML.

Some browsers have a parser switch, IIRC. Switch to best effort
mode for the important, but junk, HTML code that is out there,
inevitably, new or old. Or be more optimistic and
make an attempt at treating input text as if is was well formed
XML text.

If it is to be a cooperative component of an HTML 5 system,
it needs to play well with Javascript, CSS, and all sorts of
media and HTML 5 type storage capabilities.  (Load data from
local storage, have Javascript add some remote XML, merge that,
apply CSS, etc...)

Re: Web browser in Ada

[Peter C. Chapin]

Georg Bauhaus wrote:

> What is an HTML 5 parser supposed to be?
> 
> If it is to parse the SGML text defined by the HTML 5 grammar
> then you would, in effect, have to copy browsers' near natural language
> processing capabilities, since having only an SGML parser with little
> more than moderate error correction capabilities is by far not enough
> for HTML.
> 
> Some browsers have a parser switch, IIRC. Switch to best effort
> mode for the important, but junk, HTML code that is out there,
> inevitably, new or old. Or be more optimistic and
> make an attempt at treating input text as if is was well formed
> XML text.

HTML 5 is intended to address (fix) the current horrible mess by specifying in
a reasonably precise way exactly how erroneous documents are to be handled.
That is, all HTML 5 implementations should handle bad documents in a similar
manner. Note that HTML 5 is *not* an SGML markup... nor is it intended to be.

A fully functioning web browser in today's world needs to handle "tag soup"
documents. Maybe someday that will no longer be necessary. Still... a clean
room implementation of HTML 5, in Ada, might be a nice contribution to the
cause of creating a better web browser.

I wonder if there are any easily identifyable security critical components
that could benefit from SPARK.

Peter

Re: Web browser in Ada

[Warren]

Peter C. Chapin expounded in
news:4bd23c72$0$2399$4d3efbfe@news.sover.net: 

> Gautier write-only wrote:
> 
>> My impression is that a good part of vulnerabilities are indeed
>> within plug-ins, another good part is between the browser and a
>> plug-in (typically, browser X need to be patched but not the others
>> nor the plug-in), and the third part, important as well, is about
>> CSS, JavaScript, image storage or decoding, XML, HTML parsing and
>> other core parts of browsers.
> 
> I had actually thought that building a web browser in Ada would be a
> nice project (if only I had more time!). I'm not sure how much of a
> difference in security it would make... probably some.
> 
> Any browser that could be realistically used would need to support
> JavaScript. While an Ada JavaScript implementation might (or might
> not) be more secure than a C implementation, it seems to me that any
> vulnerability related to the JavaScript language itself would still be
> a risk. 
..
> Peter

To do it "right" would involve rewriting almost everything
above the O/S level, as you implied. Everything including
the image rendering libraries would be necessary.

The trick perhaps, is to convince the Military to do it as 
an open sourced project. ;-)

Warren

Re: Web browser in Ada

[leonid]

On Apr 23, 11:03 am, Gautier write-only <gautier_niou...@hotmail.com>
wrote:
> There are discussions from time to time, since very long, about
> writing a Web browser in Ada.
> The main idea would have a safe browser.
> Actually today's issues about security in Web browsers remarkably seem
> of the same kind as ten years ago, just a bit more frequent and acute.
> Did someone give a try ?
> I guess the following libraries would be considered:
> - AWS, for the HTTP requests
> - GtKAda, for a portable GUI
> - the least possible bindings and the most possible Ada code for
> decoding images and other contents
> _________________________________________________________
> Gautier's Ada programming --http://sf.net/users/gdemont/
> NB: For a direct answer, e-mail address on the following web site:http://www.fechtenafz.ethz.ch/wm_email.htm

Hi, you may try Webkit example in Qt4ada , as a simple web browser
http://users1.jabry.com/adastudio/index.html
Leonid

Re: Web browser in Ada

[Gautier write-only]

Thanks!
Sure, there are ways to embed existing browsers into various GUI
systems.
My question was a bit different - about the browser itself.
______________________________________________________________
Gautier's Ada programming -- http://gautiersblog.blogspot.com/
NB: For a direct answer, e-mail address on the following web site:
http://www.fechtenafz.ethz.ch/wm_email.htm