[ https://issues.apache.org/jira/browse/NET-345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002123#comment-13002123 ]
Sebb commented on NET-345: -------------------------- Todays attachements removed, as they are not needed for this issue. > Telnet client: not properly handling IAC bytes within subnegotiation messages > ----------------------------------------------------------------------------- > > Key: NET-345 > URL: https://issues.apache.org/jira/browse/NET-345 > Project: Commons Net > Issue Type: Bug > Components: Telnet > Affects Versions: 2.0 > Reporter: Archie Cobbs > Fix For: 3.0 > > Attachments: patch3.txt, patch4.txt > > > Subnegotiation messages in telnet are sent using the sequence {{IAC SB ... > IAC SE}}. > Although it's not clearly spelled out in [RFC > 854|http://tools.ietf.org/html/rfc854], any {{IAC}} ({{0xff}}) bytes inside > these messages must be escaped by doubling. Other clients do this and this is > the only behavior that makes sense. > The commons-net telnet client is failing both to escape and to unescape > {{IAC}} bytes within subnegotiation messages. Moreover, if it does receive a > valid {{IAC IAC}} sequence within a subnegotiation message, it will > incorrectly jump back to "data" input mode, discarding the message and > introducing its remainder as garbage in the data stream. > In addition, the code fails to check for an overflow of the subnegotiation > buffer, which would cause an {{ArrayIndexOutOfBounds}} exception if a > malicious peer triggered this condition. > Finally, a {{IAC SE}} sequence appearing by itself should probably be > discarded, rather than passing as a command to the handler. > I'm attaching a patch to fix these issues. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira