[Snort-sigs] [SID 36903, 37674] invalid offset value of content option

백정운 jeongun.baek at gmail.com
Tue Feb 6 00:49:37 EST 2018


Dear Snort-Team,

I had discovered something wrong in the rules, so I want to know if I am misunderstanding.

alert udp $EXTERNAL_NET any -> $HOME_NET 500 (msg:"SERVER-OTHER Cisco ASA IKEv2 invalid fragment length heap buffer overflow attempt"; flow:to_server; content:"|84 20|"; depth:2; offset:16; byte_test:2,<,8,12,relative; metadata:policy balanced-ips drop, policy security-ips drop; reference:cve,2016-1287; reference:url,tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20160210-asa-ike; classtype:attempted-admin; sid:36903; rev:2;)
alert udp $EXTERNAL_NET any -> $HOME_NET 500 (msg:"SERVER-OTHER Cisco ASA IKEv1 invalid fragment length heap buffer overflow attempt"; flow:to_server; content:"|84 10|"; depth:2; offset:16; byte_test:2,<,8,12,relative; metadata:policy balanced-ips drop, policy security-ips drop; reference:cve,2016-1287; reference:url,tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20160210-asa-ike; classtype:attempted-admin; sid:37674; rev:1;)

In the above two rules, content option seems to check "Next payload", "MjVer", "MnVer" of IKE header. According to section "3.1 The IKE Header" of RFC4306, Next Playload field was located offset 8. I wonder why the offset of the content option is 16.

RFC4306 : https://tools.ietf.org/html/rfc4306#page-41

Best regards,
Eric Baek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-sigs/attachments/20180206/02cdd627/attachment.html>


More information about the Snort-sigs mailing list