https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3440
Summary: Failure to dissect long SASL wrapped LDAP response
Product: Wireshark
Version: SVN
Platform: All
OS/Version: All
Status: NEW
Severity: Normal
Priority: Medium
Component: Wireshark
AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
ReportedBy: mat@xxxxxxxxx
Build Information:
wireshark -v
wireshark 1.1.3-SVN-27393
Copyright 1998-2009 Gerald Combs <gerald@xxxxxxxxxxxxx> and contributors.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiled with GTK+ 2.14.4, with GLib 2.18.2, with libpcap 0.9.8, with libz
1.2.3.3, with POSIX capabilities (Linux), with libpcre 7.8, without SMI,
without
c-ares, with ADNS, without Lua, with GnuTLS 2.4.1, with Gcrypt 1.4.1, with MIT
Kerberos, without GeoIP, with PortAudio V19-devel (built Mar 12 2008), without
AirPcap.
Running on Linux 2.6.27-11-generic, with libpcap version 0.9.8, GnuTLS 2.4.1,
Gcrypt 1.4.1.
Built using gcc 4.3.2.
--
This bug is simmilar to bug 2687
(https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2687).
The previous solution that consited of incrasing the threhsold before we
consider a dialog not to be SASL, has proved to be not good: In current SVN the
limit is 256k but I faced a dialog with a SASL size of 416991.
Changing the LDAP_SASL_MAX_BUF in asn1/ldap/packet-ldap-template.h is not a
good solution to my mind because puting 512k (ie. in order that my case works)
will just push a bit forward the problems but still the problem there is.*
Maybe once can wonder how it's possible to genreate such big trafic in one LDAP
request the response lies into synchronisation tools like MIIS of ADAM of
Microsoft who tends to request all the directory when not very well configured.
To me the real solution is to do for SASL like it has been done for SSL: write
in ldap_info that had an authentification negotiation just before and so the
following frame SASL will be used.
That's not simple I guess and it has a lot of implication. Another solution is
to raise the bar up to 752 MB as an SASL size, I think this limit will not be
reached soon (but still there is a probability ...) this value correspond 0x29
* 2^24, that when the first byte is < 0x30 (which is the normal value) and 3
others are 0xFF.
In order to still be able to recorgnize SLDAP traffic, the SSL test must be
done first (in my mind) because it seems that it is based on previous state
analysis instead of simple guess.
If this solution seems OK I can produce a patch for this in a few days.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
