[Wireshark-dev] OID/BER memory oddness
I was running some valgrind fuzzing and I got a file that produces the following valgrind trace: ==8013== Invalid read of size 1 ==8013==at 0x95F89D0: g_str_hash (ghash.c:1732) ==8013==by 0x95F8058: g_hash_table_lookup (ghash.c:365) ==8013==by 0x65DE56E: call_ber_oid_callback (packet-ber.c:518) ==8013==by 0x65DF2BD: dissect_ber_sequence (packet-ber.c:2285) ==8013==by 0x6DB5A8F: dissect_x509af_AlgorithmIdentifier (x509af.cnf:98) ==8013==by 0x65DF2BD: dissect_ber_sequence (packet-ber.c:2285) ==8013==by 0x6DB5BCF: dissect_x509af_T_signedCertificate (x509af.cnf:159) ==8013==by 0x65DF2BD: dissect_ber_sequence (packet-ber.c:2285) ==8013==by 0x6DB5B8F: dissect_x509af_Certificate (x509af.cnf:175) ==8013==by 0x6B50365: dissect_ssl3_handshake (packet-ssl.c:3131) ==8013==by 0x6B51E8A: dissect_ssl3_record (packet-ssl.c:1791) ==8013==by 0x6B52854: dissect_ssl (packet-ssl.c:909) ==8013== Address 0x12f6a420 is 0 bytes inside a block of size 68 free'd ==8013==at 0x4C2B60C: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==8013==by 0x64DE30C: emem_free_all (emem.c:1240) ==8013==by 0x64E01BA: epan_dissect_run_with_taps (epan.c:333) ==8013==by 0x4134FD: process_packet (tshark.c:3453) ==8013==by 0x40BAA3: main (tshark.c:3256) In one sense the problem is easy to trace: the oid resolution code is returning the resolved string in an ep-allocated buffer, which is then getting freed and subsequently used. However, I'm having trouble tracking down exactly where this resolved oid is being persisted between packets, since the way I've followed the trace makes it look like the oid resolution and subsequent use are happening in the same packet, in which case it shouldn't be freed in the middle. I'm hoping this will be obvious to somebody who actually knows the BER/OID code. If not I'll file a bugzilla and attach the capture. Evan ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] OID/BER memory oddness
Evan Huus wrote: In one sense the problem is easy to trace: the oid resolution code is returning the resolved string in an ep-allocated buffer, which is then getting freed and subsequently used. However, I'm having trouble tracking down exactly where this resolved oid is being persisted between packets, since the way I've followed the trace makes it look like the oid resolution and subsequent use are happening in the same packet, in which case it shouldn't be freed in the middle. I'm hoping this will be obvious to somebody who actually knows the BER/OID code. If not I'll file a bugzilla and attach the capture. If you're asking what I think you're asking, as names get resolved, they're added to a static tree called oid_root in oids.c. The children of that tree are supposed to be in wmem_epan_scope(). There are three oid_add functions that add items to that tree. One thing that may help resolving this is to set the environment variable WIRESHARK_DEBUG_MIBS to an integer value in the range 1 to 10. (Higher numbers mean more verbose output.) I'd like to have eliminated the ep_alloc() calls within oids.c in favor of the newer wmem_ calls, but didn't have the time to do that properly and it seemed that it might break other things. That's why I also added the oid unit tests a few months ago. If that doesn't help, let me know where I went astray and I can try again. Ed ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] OID/BER memory oddness
On Sun, Dec 15, 2013 at 12:33 PM, Ed Beroset bero...@mindspring.com wrote: Evan Huus wrote: In one sense the problem is easy to trace: the oid resolution code is returning the resolved string in an ep-allocated buffer, which is then getting freed and subsequently used. However, I'm having trouble tracking down exactly where this resolved oid is being persisted between packets, since the way I've followed the trace makes it look like the oid resolution and subsequent use are happening in the same packet, in which case it shouldn't be freed in the middle. I'm hoping this will be obvious to somebody who actually knows the BER/OID code. If not I'll file a bugzilla and attach the capture. If you're asking what I think you're asking, as names get resolved, they're added to a static tree called oid_root in oids.c. The children of that tree are supposed to be in wmem_epan_scope(). There are three oid_add functions that add items to that tree. One thing that may help resolving this is to set the environment variable WIRESHARK_DEBUG_MIBS to an integer value in the range 1 to 10. (Higher numbers mean more verbose output.) Hmm, maybe I misspoke, it doesn't really seem to be *resolution* exactly. The call I'm looking at is to oid_encoded2string() which doesn't appear to use the static tree. If you follow the normal path it ends up in rel_oid_subid2string() which returns an ep-allocated buffer. This buffer is then being stored somewhere I can't find, and is showing up in some later packet after being freed. I'd like to have eliminated the ep_alloc() calls within oids.c in favor of the newer wmem_ calls, but didn't have the time to do that properly and it seemed that it might break other things. That's why I also added the oid unit tests a few months ago. Ya, the usual pattern for this type of conversion seems to be: 1. Add a parameter for a wmem scope, use that instead of ep or se memory in the function. 2. For calls to the function within packet dissection code, just pass wmem_packet_scope() and it will behave as it used to. 3. For other calls (from the GUI, etc) figure out what the appropriate scope actually is and use that. This usually just ends up being manually managed, so passing NULL for the scope. Depending on how many callers there are it can be a lot of work. If that doesn't help, let me know where I went astray and I can try again. The part that's confusing me is that somehow actx-external.direct_reference seems to be getting a pointer to this stale ep-allocated buffer, but I can't find anywhere in the call stack that value could be set to such a stale buffer. Thanks, Evan ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] OID/BER memory oddness
Evan Huus wrote: The part that's confusing me is that somehow actx-external.direct_reference seems to be getting a pointer to this stale ep-allocated buffer, but I can't find anywhere in the call stack that value could be set to such a stale buffer. That would probably be dissect_ber_OBJECT_IDENTIFIER which calls dissect_ber_object_identifier_str(), which calls dissect_ber_any_oid_str() which calls oid_encoded2string. Tracing through the ASN1 code is not very easy in my experience. I have also been thinking that it would be nice to modify asn2wrs.py so that it would use the new style encapsulated hf variables but I haven't yet had time to dig into that. Such a change would require some careful testing of all of the ASN1 protocols. Ed ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] OID/BER memory oddness
Ed Beroset wrote: Evan Huus wrote: The part that's confusing me is that somehow actx-external.direct_reference seems to be getting a pointer to this stale ep-allocated buffer, but I can't find anywhere in the call stack that value could be set to such a stale buffer. That would probably be dissect_ber_OBJECT_IDENTIFIER which calls dissect_ber_object_identifier_str(), which calls dissect_ber_any_oid_str() which calls oid_encoded2string. As a correction, I was looking a little more at your original message with the trace, and I think that in your case it's more likely to be the call to dissect_x509af_T_extnId(). It's the line that's created by the DEFAULT_BODY line in asn1/x509af/x509af.cnf line 90. If you look at the generated code, you'll see that it creates a call to dissect_ber_object_identifier_str() the last parameter of which is actx-external.direct_reference. Ed ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Where is packet-isdn-sup-table31.c?
It should be a temporary file, try adding -k to A2W_FLAGS in makefile.common: A2W_FLAGS= -b -k Regards Anders Maynard, Chris skrev 2013-12-13 23:19: Hmm, I'm on Windows 7 x64 using nmake and it never gets generated. I must be missing something, but I'm out of time for today. -Original Message- From: wireshark-dev-boun...@wireshark.org [mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Bálint Réczey Sent: Friday, December 13, 2013 5:01 PM To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] Where is packet-isdn-sup-table31.c? cmake ... make -C asn1/isdn-sup/ generated it for me in asn1/isdn-sup/ Cheers, Balint 2013/12/13 Christopher Maynard christopher.mayn...@gtech.com: In asn1/isdn-sup/packet-isdn-sup-template.c at line 110, there is: #include packet-isdn-sup-table31.c I'm unable to locate this file. Can someone more familiar with asn1 dissectors point me in the right direction? ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
