Re: snort2: curious code in rfc5987_attr_char()
Dave Killion via Snort-devel <[email protected]> Thu, 19 Dec 2019 15:23:57 -0800
| Newsgroups | gmane.comp.security.ids.snort.devel |
|---|---|
| Message-ID | <CACOJjd+rjTvwwjWXvmqzVhZyVfpMrq0sLwhZFiEUE_ts4U1P0w@mail.gmail.com> |
--===============1378488737289373000== Content-Type: multipart/alternative; boundary="0000000000001ecde3059a16dd80" --0000000000001ecde3059a16dd80 Content-Type: text/plain; charset="UTF-8" Good catch Bob - the OR's combined with the negates means it always returns true, thus nullifying the check in the first place. On Thu, Dec 19, 2019 at 3:17 PM Bob Cook via Snort-devel < [email protected]> wrote: > Hello, > > I've been reviewing a little bit of the snort code and this got flagged by > a static analyzer: > > src\preprocessors\snort_httpinspect.c:3891 (snort-2.9.15) > > static inline bool rfc5987_attr_char(u_char c) > { > return rfc_2616_token(c) && ((c != '*') || (c != '\'') || (c != '%')); > } > > The logical OR operators are likely supposed to be logical AND operators, > which would make way more sense given the definition of RFC 5987. > > Anyone else noticed this before? The code isn't new, seems like it's been > around for a while and still exists in 2.9.15. > > The side effect of this behavior would appear to be pretty minor, as this > function is only used in parsing the Content-Disposition header, but > figured it's still worth pointing out / asking about. There may be some > history that I'm not aware of. > > Thanks, > Bob Cook > Sophos > > _______________________________________________ > Snort-devel mailing list > [email protected] > https://lists.snort.org/mailman/listinfo/snort-devel > > Please visit http://blog.snort.org for the latest news about Snort! > -- Dave Killion --0000000000001ecde3059a16dd80 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Good catch Bob - the OR's combined with the negates me= ans it always returns true, thus nullifying the check in the first place.<d= iv><br></div><div><br></div></div><br><div class=3D"gmail_quote"><div dir= =3D"ltr" class=3D"gmail_attr">On Thu, Dec 19, 2019 at 3:17 PM Bob Cook via = Snort-devel <<a href=3D"mailto:[email protected]">snort-devel@= lists.snort.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" s= tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad= ding-left:1ex">Hello,<br> <br> I've been reviewing a little bit of the snort code and this got flagged= by a static analyzer:<br> <br> src\preprocessors\snort_httpinspect.c:3891 (snort-2.9.15)<br> <br> static inline bool rfc5987_attr_char(u_char c)<br> {<br> =C2=A0 =C2=A0 return rfc_2616_token(c) && ((c !=3D '*') || = (c !=3D '\'') || (c !=3D '%'));<br> }<br> <br> The logical OR operators are likely supposed to be logical AND operators, w= hich would make way more sense given the definition of RFC 5987.<br> <br> Anyone else noticed this before? The code isn't new, seems like it'= s been around for a while and still exists in 2.9.15.<br> <br> The side effect of this behavior would appear to be pretty minor, as this f= unction is only used in parsing the Content-Disposition header, but figured= it's still worth pointing out / asking about. There may be some histor= y that I'm not aware of.<br> <br> Thanks,<br> Bob Cook<br> Sophos<br> <br> _______________________________________________<br> Snort-devel mailing list<br> <a href=3D"mailto:[email protected]" target=3D"_blank">Snort-deve= [email protected]</a><br> <a href=3D"https://lists.snort.org/mailman/listinfo/snort-devel" rel=3D"nor= eferrer" target=3D"_blank">https://lists.snort.org/mailman/listinfo/snort-d= evel</a><br> <br> Please visit <a href=3D"http://blog.snort.org" rel=3D"noreferrer" target=3D= "_blank">http://blog.snort.org</a> for the latest news about Snort!<br> </blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"= class=3D"gmail_signature">Dave Killion<br></div> --0000000000001ecde3059a16dd80-- --===============1378488737289373000== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Snort-devel mailing list [email protected] https://lists.snort.org/mailman/listinfo/snort-devel Please visit http://blog.snort.org for the latest news about Snort! --===============1378488737289373000==--