You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Archie Cobbs (JIRA)" <ji...@apache.org> on 2010/11/19 23:54:13 UTC

[jira] Created: (NET-345) Telnet client: not properly handling IAC bytes within subnegotiation messages

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
         Attachments: patch3.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.
-
You can reply to this email to add a comment to the issue online.


[jira] Updated: (NET-345) Telnet client: not properly handling IAC bytes within subnegotiation messages

Posted by "Sebb (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/NET-345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sebb updated NET-345:
---------------------

    Attachment:     (was: combined_NET-343_NET-344_NET-345_patch.txt)

> 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

        

[jira] Commented: (NET-345) Telnet client: not properly handling IAC bytes within subnegotiation messages

Posted by "Sebb (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/NET-345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002032#comment-13002032 ] 

Sebb commented on NET-345:
--------------------------

This issue is marked as resolved. 

If there are any changes that have not been applied, please attach a patch that fixes just the items necessary to complete 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: combined_NET-343_NET-344_NET-345_patch.txt, 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

        

[jira] Commented: (NET-345) Telnet client: not properly handling IAC bytes within subnegotiation messages

Posted by "Archie Cobbs (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/NET-345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002117#comment-13002117 ] 

Archie Cobbs commented on NET-345:
----------------------------------

Bleh! Sorry, ignore that last comment and patch ({{discard_IAC_SE.txt}}). That patch was already included in a slightly different form.

My apologies. I'm getting confused trying to merge all the patches.


> 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: combined_NET-343_NET-344_NET-345_patch.txt, discard_IAC_SE.txt, 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

        

[jira] Commented: (NET-345) Telnet client: not properly handling IAC bytes within subnegotiation messages

Posted by "Sebb (JIRA)" <ji...@apache.org>.
    [ 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

        

[jira] Updated: (NET-345) Telnet client: not properly handling IAC bytes within subnegotiation messages

Posted by "Sebb (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/NET-345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sebb updated NET-345:
---------------------

    Fix Version/s: 3.0

> 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

        

[jira] Updated: (NET-345) Telnet client: not properly handling IAC bytes within subnegotiation messages

Posted by "Archie Cobbs (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/NET-345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Archie Cobbs updated NET-345:
-----------------------------

    Attachment: discard_IAC_SE.txt

Thanks. Just the last bit of the combined patch was left out, i.e., discarding an IAC SE sequence appearing by itself.


> 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: combined_NET-343_NET-344_NET-345_patch.txt, discard_IAC_SE.txt, 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

        

[jira] Commented: (NET-345) Telnet client: not properly handling IAC bytes within subnegotiation messages

Posted by "Archie Cobbs (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/NET-345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12934573#action_12934573 ] 

Archie Cobbs commented on NET-345:
----------------------------------

FYI, the latest version of my combined patch to fix NET-343, NET-344, and NET-345 can be found [here|http://jvser.googlecode.com/svn/trunk/src/commons-net-telnet/patch.txt].

Please use this version as I'll be keeping it up to date.


> 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
>         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.
-
You can reply to this email to add a comment to the issue online.


[jira] Updated: (NET-345) Telnet client: not properly handling IAC bytes within subnegotiation messages

Posted by "Archie Cobbs (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/NET-345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Archie Cobbs updated NET-345:
-----------------------------

    Attachment: patch4.txt

> 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
>         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.
-
You can reply to this email to add a comment to the issue online.


[jira] Updated: (NET-345) Telnet client: not properly handling IAC bytes within subnegotiation messages

Posted by "Archie Cobbs (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/NET-345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Archie Cobbs updated NET-345:
-----------------------------

    Attachment: combined_NET-343_NET-344_NET-345_patch.txt

Attaching combined patch for NET-343, NET-344, NET-345.


> 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: combined_NET-343_NET-344_NET-345_patch.txt, 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

        

[jira] Resolved: (NET-345) Telnet client: not properly handling IAC bytes within subnegotiation messages

Posted by "Sebb (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/NET-345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sebb resolved NET-345.
----------------------

    Resolution: Fixed

Thanks, applied patches with a few minor changes.
E.g. output is buffered, so simpler to double the IACs on the fly rather than using another buffer.

> 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
>         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

        

[jira] Updated: (NET-345) Telnet client: not properly handling IAC bytes within subnegotiation messages

Posted by "Archie Cobbs (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/NET-345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Archie Cobbs updated NET-345:
-----------------------------

    Attachment: patch3.txt

> 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
>         Attachments: patch3.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.
-
You can reply to this email to add a comment to the issue online.


[jira] Updated: (NET-345) Telnet client: not properly handling IAC bytes within subnegotiation messages

Posted by "Sebb (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/NET-345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sebb updated NET-345:
---------------------

    Attachment:     (was: discard_IAC_SE.txt)

> 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