From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,e219d94b946dfc26 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news2.google.com!news.germany.com!news.ecp.fr!news.jacob-sparre.dk!pnx.dk!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Ada.Command_Line and wildcards Date: Tue, 27 Feb 2007 14:43:20 -0600 Organization: Jacob's private Usenet server Message-ID: References: <45dcaed8_6@news.bluewin.ch> <1172132169.423514.271890@s48g2000cws.googlegroups.com> <45E1B7AA.30804@obry.net> <1dpvltpykld8r$.1rn2ewhc0itjt$.dlg@40tude.net> <1172587938.237094.134530@m58g2000cwm.googlegroups.com> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: jacob-sparre.dk 1172608896 18737 69.95.181.76 (27 Feb 2007 20:41:36 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Tue, 27 Feb 2007 20:41:36 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Xref: g2news2.google.com comp.lang.ada:9583 Date: 2007-02-27T14:43:20-06:00 List-Id: "Hyman Rosen" wrote in message news:1172587938.237094.134530@m58g2000cwm.googlegroups.com... > On Feb 26, 7:34 pm, "Randy Brukardt" 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.