full-disclosure - Microsoft Windows and *nix Telnet PortNumber Argument Obfuscation

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>] [<thread-prev] [day] [month] [year] [list]

Date: Sun Jun 12 07:46:22 2005
From: umphress at gmail.com (Chris Umphress)
Subject: Microsoft Windows and *nix Telnet PortNumber
	Argument Obfuscation

> OK.  Fair enough, but at least some people found it "informative".  The
> technique described probably does affect many networking tools, as you
> stated, but one should ask if this is a proper coding technique or not
> (think secure code).  The input does not map to the expected output --
> and the user should have been told that the port number is out of range.
> Otherwise, what if he thinks 65571 is a valid port after executing that
> command?  He may be naive, but shouldn't the telnet programmer let him
> know that he is mistaken in his port choice?
> 
> As an analogy, it is also true that a C programmer could pull some nice
> tricks to optimize his code, but that code may confuse another
> programmer trying to understand it.  This is a system, like anything
> else, and things are based on give/take.  I don't see why allowing this
> to happen actually helps anyone but the telnet programmer -- because it
> could confuse many users.

Perhaps. If the user is using telnet (especially today), I would
generally assume they know a little bit about how their system works.
In today's world, sometimes we forget about memory and file size
optimizations. While telnet is not normally one of those files that
technicians try to cram onto their diagnostic Floppies/CDs, there
might be an occasion when it would be nice to save those few extra
bytes or kilobytes that these messages would take up.

While I don't disagree with you that user-friendly programs are nice,
there are times when other optimizations are favoured more.
-- 
Chris Umphress <http://daga.dyndns.org/>