Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   Perl Misc (http://www.velocityreviews.com/forums/f67-perl-misc.html)
-   -   readline - possible security hole (http://www.velocityreviews.com/forums/t902479-readline-possible-security-hole.html)

Krivenok Dmitry 03-30-2007 12:50 PM

readline - possible security hole
 
Hello All!

Suppose I use readline subroutine in my server application to read
one
line from a socket.
Obviously, there may be a client, that may write something like this:

my $request = "12345";
while(1)
{
$sock->send($request);
}

In this case readline() never returns, but its internal buffer will
continuously
grow.
Eventually, the internal buffer becomes overfull.

I can't find a way to specify maximum buffer size.
readline's prototype is "readline EXPR".
Thus, it seems to me that there is no way to specify max buffer size
except globally. But how?
And what value should return readline() in this case?

Is it really security hole?
Any comments?


Paul Lalli 03-30-2007 03:03 PM

Re: readline - possible security hole
 
On Mar 30, 8:50 am, "Krivenok Dmitry" <krivenok.dmi...@gmail.com>
wrote:
> Hello All!
>
> Suppose I use readline subroutine in my server application to read
> one line from a socket.
> Obviously, there may be a client, that may write something like this:
>
> my $request = "12345";
> while(1)
> {
> $sock->send($request);
> }
>
> In this case readline() never returns, but its internal buffer will
> continuously
> grow.
> Eventually, the internal buffer becomes overfull.


"Hello, Doctor, suppose it hurts when I raise my right arm over my
head...."

See also:
perldoc -f read

> I can't find a way to specify maximum buffer size.
> readline's prototype is "readline EXPR".
> Thus, it seems to me that there is no way to specify max buffer size
> except globally. But how?


Please read the documentation for the function you're using.

perldoc -f readline
readline EXPR
[...]
Note that the
notion of "line" used here is however you may have
defined it with $/ or $INPUT_RECORD_SEPARATOR). See
"$/" in perlvar.

perldoc perlop
IO::Handle->input_record_separator(EXPR)
$INPUT_RECORD_SEPARATOR
$RS
$/ The input record separator, newline by default.
[...]
Setting $/ to a reference to an integer, scalar
containing an integer, or scalar that's convertible
to an integer will attempt to read records instead
of lines, with the maximum record size being the
referenced integer. So this:

local $/ = \32768; # or \"32768", or \
$var_containing_32768
open my $fh, $myfile or die $!;
local $_ = <$fh>;

will read a record of no more than 32768 bytes from
FILE.


> And what value should return readline() in this case?
>
> Is it really security hole?
> Any comments?


I don't consider poor programming practices to be security holes in
the language.

Paul Lalli


Peter J. Holzer 03-30-2007 06:08 PM

Re: readline - possible security hole
 
On 2007-03-30 15:03, Paul Lalli <mritty@gmail.com> wrote:
> On Mar 30, 8:50 am, "Krivenok Dmitry" <krivenok.dmi...@gmail.com>
> wrote:
>> Suppose I use readline subroutine in my server application to read
>> one line from a socket.
>> Obviously, there may be a client, that may write something like this:
>>
>> my $request = "12345";
>> while(1)
>> {
>> $sock->send($request);
>> }
>>
>> In this case readline() never returns, but its internal buffer will
>> continuously
>> grow.
>> Eventually, the internal buffer becomes overfull.

>
> "Hello, Doctor, suppose it hurts when I raise my right arm over my
> head...."
>
> See also:
> perldoc -f read
>
>> I can't find a way to specify maximum buffer size.
>> readline's prototype is "readline EXPR".
>> Thus, it seems to me that there is no way to specify max buffer size
>> except globally. But how?

>
> Please read the documentation for the function you're using.

[...]
> IO::Handle->input_record_separator(EXPR)
> $INPUT_RECORD_SEPARATOR
> $RS
> $/ The input record separator, newline by default.
> [...]
> Setting $/ to a reference to an integer, scalar
> containing an integer, or scalar that's convertible
> to an integer will attempt to read records instead
> of lines,


This isn't very useful if you want to implement a line oriented protocol
(like many internet protocols). At least it isn't any more useful than
plain read.

>> And what value should return readline() in this case?
>>
>> Is it really security hole?
>> Any comments?

>
> I don't consider poor programming practices to be security holes in
> the language.


I'm not sure if reimplementing readline with read or getc is much better
programming practice. If I was writing a forking server I'd probably
just set a suitable resource limit on memory usage and let the OS kill
the process if it gets too big. That also has the advantage that it
also works if a small input somehow causes the process to consume lots
of memory.

hp

--
_ | Peter J. Holzer | Blaming Perl for the inability of programmers
|_|_) | Sysadmin WSR | to write clearly is like blaming English for
| | | hjp@hjp.at | the circumlocutions of bureaucrats.
__/ | http://www.hjp.at/ | -- Charlton Wilbur in clpm

noident@my-deja.com 04-01-2007 11:32 PM

Re: readline - possible security hole
 
> I can't find a way to specify maximum buffer size.
> readline's prototype is "readline EXPR".
> Thus, it seems to me that there is no way to specify max buffer size
> except globally. But how?


You can use sysread(). There you can specify the buffer size. It's not
line-oriented though, so you'll have to look for the new-line in the
buffer yourself.



All times are GMT. The time now is 05:00 AM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.