Re: Ada.Command_Line and wildcards

["Randy Brukardt" <randy@rrsoftware.com>]

"Hyman Rosen" <hyman.rosen@gmail.com> wrote in message
news:1172587938.237094.134530@m58g2000cwm.googlegroups.com...
> On Feb 26, 7:34 pm, "Randy Brukardt" <r...@rrsoftware.com> wrote:
> > The problem is that if it doesn't fit, you can't recover
>
> Granted, but that's not really the point. On a modern computer system,
> given that it's reading input from a file or standard input, the
> programmer can reasonably expect that there are at least many tens of
> megabytes available to be allocated. Sure there can be inputs that
> will exceed that, but then you're really in a different domain.
>
> Think of it this way - when you decide to sort data, you need to
> choose between internal and external sorts. You can't do that without
> a notion of a threshold size. Clearly that size has increased over the
> years. Reading input is similar. Many programs can now very reasonably
> expect to read in their entire input into memory at once before
> processing any of it, and if that's not going to work because of
> allocation on the stack then there should be an alternative.

True, but recovery *is* the point if you're at all worried about security.
These days, you have to assume that all files and all other user input are
corrupted in some way. Ignoring the possibility is only legitimate for
programs only used in tightly controlled circumstances (and there are not
many of those).

It is OK to let the program run out of memory if that case can only cause a
DoS to the attacker. (Who cares if the attacker is served?) But running out
of memory can cause a DoS to *all* tasks in the program, and that could
cause a DoS to all users of the program.

Take our web server. It uses a fixed size buffer to read commands from the
Internet. Because of the behavior of the procedure Get_Line, if the command
is too long, it will merely be truncated (and the fact that that happened
can be detected). So even if the case isn't handled explicitly, nothing bad
could happen to anyone other than the attacker (and if it is handled
explicitly, the attacker simply will be given an error message). OTOH, the
function Get_Line would use an arbitrary amount of memory in that case. So,
if an attacker fed a sufficiently large command to the server, it could
cause the server to run out of memory and thus disrupt the other tasks
handling commands from other clients. That could result in a general DoS,
and that's not acceptable.

Thus, its really only safe to use function Get_Line in single-tasking
programs for which the failure to handle user input does not cause
corruption. There are of course many such programs, which is why we included
a function Get_Line. But it has to be used with care _ I worry that it will
not be, and thus some of Ada's security will be compromised.

In any case, current Ada supports what you want. So further griping on this
subject is uncalled for... (There are plenty of other subjects where you
could find a legitimate gripe...I recommend complaining about one of them.
;-)

                                                Randy.