semio has asked for the wisdom of the Perl Monks concerning the following question:

I recently performed a security scan in my environment and I noticed a that on one application in particular( name withheld to protect the vendor) an error message was generated when I scanned a particular, listening port. I wanted to investigate this further so I put together a quick perl script to connect to the suspect port repeatedly.
#!d:/perl/bin/perl -w use strict; use Socket; my $line = "A" x 1000; my ($iaddr, $sin, $proto); my $max = 2000; my $port = <suspect port here>; while (1) { $proto = getprotobyname('tcp'); socket(SOCK, PF_INET, SOCK_STREAM, $proto); $iaddr = gethostbyname('IP address of device'); $sin = sockaddr_in($port, $iaddr); connect(SOCK, $sin); send(SOCK,$line,0,$iaddr); }
This resulted in killing the application listening to this port and the processor utilization shot to 100%. I'm interested in knowing if there is a better way to stress test network applications with Perl and, in particular, the experiences of other monks when working on a problem such as this. I will also be notifying the vendor but I want to spend a few more days looking at this.
cheers, -semio

Replies are listed 'Best First'.
Re: application stress testing with Perl
by sauoq (Abbot) on Sep 24, 2002 at 00:27 UTC
    ( name withheld to protect the vendor)

    What interest do you really have in protecting the vendor? If you found this with a simple port scan, it is likely that the vendor is already aware of it. You might research a bit to see if it is already a known issue. Sadly, many vendors don't act very quickly on problems like this unless pushed to do so.

    I will also be notifying the vendor but I want to spend a few more days looking at this.

    If you really feel this is a security vulnerability, and it sounds like it could at least be a DoS vulnerability, you should do the community a favor and report it immediately. There is no good reason to wait. My suggestion is that you fill out CERT's Vulnerability Reporting Form in addition to contacting the vendor. Let the vendor know you filled it out.

    I am not advocating that you make it public although some might argue the merit of that approach.

    -sauoq
    "My two cents aren't worth a dime.";
    
      I'm personally of the opinion security flaws should be made public. Of course there will be people out there who will exploit the information, however, who's to say you're the 1st to discover the bug?

      Making the bug public at least gives users the opportunity to do *something* (extra monitoring, taking down the service etc etc), rather than being blindsided by a previously "unknown" attack...

      I'm also a fan of letting the vendor know about the exploit before going public, so at least they have some time to respond...