full-disclosure - Re: SSL Capable NetCat and more

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <1226363674.7464121301296121340.JavaMail.root@zcs-mbs03.it.mtu.edu>
Date: Mon, 28 Mar 2011 03:08:41 -0400 (EDT)
From: Ryan Sears <rdsears@....edu>
To: GomoR <rpt6@...or.org>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: SSL Capable NetCat and more

Please, correct me if I'm wrong, but a stack overflow in the arguments for something like socat has a very very low impact (or probability of exploitation). The only way one can influence the program to do something is by overflowing the arguments, so unless it was used in a script or something of that sort in an automatic fashion, it's highly unlikely this will be weaponized.

Having said that, having automatic memory allocation/management through a lot of the modern day scripting languages is a definite plus.

I think he's looking at it like this, because this is what I was thinking when I first read about it:

(Rough outline of language abstraction layers)

        ||
        ||
+-----------------+
| High-level lang |
|  (Java, etc)    |
+-----------------+
        ||
        ||==> SCNC
        ||
+-------------------+
|  Mid-level lang.  |
| (perl,python,etc) |
+-------------------+
        ||
        ||==> Socat, Ncat, Cryptcat 
        ||
+-----------------+
| Low-level lang. |
|  (C, ASM, etc)  |
+-----------------+

Writing something in a lower-level language typically means increased speed and a lighter footprint. You can do these same sorts of connection relaying on a system that might not have perl installed in it. Granted, it isn't common to find a system without perl now-a-days, but if you need to install CPAN modules or something that's MORE of an overhead. That sort of thing starts to adds up, and if you can write a tiny little program to do the same thing (statically compiled for more portability) it's going to be better off. 

I like the concept and the idea though, as it provides some good flexibility if the target won't notice a perl script getting run, but notices arbitrary executables or something of the sort. 

Ryan Sears

----- Original Message -----
From: "GomoR" <gomor-fd@...or.org>
To: full-disclosure@...ts.grok.org.uk
Sent: Monday, March 28, 2011 2:47:28 AM GMT -05:00 US/Canada Eastern
Subject: Re: [Full-disclosure] SSL Capable NetCat and more

On Sun, Mar 27, 2011 at 02:23:03PM -0700, Zach C. wrote:
> Okay, and also let me rephrase the question: what does your tool do that *
> socat* doesn't?

Better question ;)

scnc is written in Perl, and does not suffer from stack 
overflows:

http://www.dest-unreach.org/socat/
2010/08/02: A stack overflow vulnerability has been fixed 
that could be triggered when command line arguments were 
longer than 512 bytes. Fixed versions are 1.7.1.3 and 
2.0.0-b4. See socat security advisory 2 for details.

This one is from command line, maybe the next will be in 
the server mode or whatever.

Regards,

-- 
  ^  ___  ___             http://www.GomoR.org/          <-+
  | / __ |__/            Senior Security Engineer          |
  | \__/ |  \     ---[ zsh$ alias psed='perl -pe ' ]---    |
  +-->  Net::Frame <=> http://search.cpan.org/~gomor/  <---+

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/