This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

SSHV2 Overly large number

0

hello,

can you explain to me the significance of this warning : "Expert Information ( Warn / Protocol) : Overly large number"

asked 23 Sep '15, 11:17

rebanubtd's gravatar image

rebanubtd
6224
accept rate: 0%


2 Answers:

1

According to the code, that's the packet length in the key exchange.

File: packet-ssh.c - ssh_dissect_key_exchange()

    plen = tvb_get_ntohl(tvb, offset) ;
REMOVED CODE ....

/*
 * Need to check plen > 0x80000000 here
 */

ti = proto_tree_add_uint(tree, hf_ssh_packet_length, tvb,
                offset, 4, plen);
if (plen >= 0xffff) {
    expert_add_info_format(pinfo, ti, &ei_ssh_packet_length, "Overly large number %d", plen);
    plen = remain_length-4;
}</code></pre><p>So, the SSH dissector checks if the packet length is larger than 0xffff. According to the <a href="https://tools.ietf.org/html/rfc4253">SSH RFC</a>, there is a <a href="https://tools.ietf.org/html/rfc4253#section-6.1">max packet length that MUST be supported</a> by any implementation, which is 32768 bytes (0x8000), and 'implementations SHOULD support longer packets, where they might be needed'.</p><p>So, I guess the check for 0xFFFF is an arbitrary max length chosen by the developer of the SSH dissector, probably based on the max size of a TCP segment.</p><p>Without the capture file, I can't say more than that ;-)</p><p>Regards<br />

Kurt

answered 23 Sep ‘15, 12:56

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
accept rate: 15%

Thanks for your answer . How Can I Send you capture ?

(24 Sep ‘15, 11:00) rebanubtd

Load it into dropbox, google drive, etc. and post the link here.

(24 Sep ‘15, 11:23) Kurt Knochner ♦

You can see “valid” values up until frame #16 and the frame length is in all cases part of the captured data.

I believe “something” is modifying the payload of the frames, because for some frames with “invalid” frame sizes, you also get unknown messages codes. So, either this is a totally modified SSH protocol (which I don’t believe), or there is an error during frame transmission and/or during the capturing process.

(28 Sep ‘15, 14:32) Kurt Knochner ♦

1

The message "SSHV2 Overly large number" is due to slicing the packets to 100 byte. I have tested and reproduced it at home. The thing why evrything went fine until frame #16 is because in Frame #14 the key exchange is completed so far that the packets could be encrypted. And after that, the packet length is in accordance to the RFC(https://tools.ietf.org/html/rfc4253) encrypted.

SSH Header (unsliced) of first Packet after the "Client: New Keys" packet. alt text

answered 29 Sep '15, 12:27

Christian_R's gravatar image

Christian_R
1.8k2625
accept rate: 16%

edited 29 Sep '15, 12:29

I have tested and reproduced it at home.
...
And after that, the packet length is in accordance to the RFC(https://tools.ietf.org/html/rfc4253) encrypted

O.K. good to know! Thanks.

(29 Sep '15, 15:04) Kurt Knochner ♦