readline - possible security hole

Discussion in 'Perl Misc' started by Krivenok Dmitry, Mar 30, 2007.

  1. 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?
    Krivenok Dmitry, Mar 30, 2007
    #1
    1. Advertising

  2. Krivenok Dmitry

    Paul Lalli Guest

    On Mar 30, 8:50 am, "Krivenok Dmitry" <>
    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
    Paul Lalli, Mar 30, 2007
    #2
    1. Advertising

  3. On 2007-03-30 15:03, Paul Lalli <> wrote:
    > On Mar 30, 8:50 am, "Krivenok Dmitry" <>
    > 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
    | | | | the circumlocutions of bureaucrats.
    __/ | http://www.hjp.at/ | -- Charlton Wilbur in clpm
    Peter J. Holzer, Mar 30, 2007
    #3
  4. Krivenok Dmitry

    Guest

    > 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.
    , Apr 2, 2007
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. LL

    Security hole?

    LL, Oct 21, 2003, in forum: ASP .Net
    Replies:
    3
    Views:
    514
    Jerry III
    Oct 23, 2003
  2. nicholas
    Replies:
    3
    Views:
    838
    nicholas
    Oct 4, 2004
  3. Patrick Olurotimi Ige

    Huge security hole in .NET: Java creator

    Patrick Olurotimi Ige, Feb 7, 2005, in forum: ASP .Net
    Replies:
    4
    Views:
    334
    Kevin Spencer
    Feb 7, 2005
  4. Andrew Thompson

    Is this a security hole?

    Andrew Thompson, Aug 6, 2004, in forum: Java
    Replies:
    7
    Views:
    392
    Andrew Thompson
    Aug 6, 2004
  5. Blair P. Houghton
    Replies:
    19
    Views:
    506
    Blair P. Houghton
    Feb 2, 2006
Loading...

Share This Page