search

mfontanini / libtins

High-level, multiplatform C++ network packet sniffing and crafting library.
http://libtins.github.io/
BSD 2-Clause "Simplified" License
1.89k stars 373 forks source link

Issue with parsing certain EAP packets #221

Open christophert opened 7 years ago

christophert commented 7 years ago

The library is unable to parse any EAPOL-Start or Identity packets included in this capture file.

The EAPOL-Start packet throws a backtrace when attempting to decode the header because of the packet indicating that the length is 0?

  what():  Malformed packet
Program received signal SIGABRT, Aborted.

__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51

51      ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) backtrace
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x00007ffff6cd83fa in __GI_abort () at abort.c:89
#2  0x00007ffff75ef0ad in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3  0x00007ffff75ed066 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4  0x00007ffff75ed0b1 in std::terminate() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5  0x00007ffff75ed2c9 in __cxa_throw () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#6  0x00007ffff7b7a938 in Tins::EAPOL::from_bytes (buffer=<optimized out>, total_sz=<optimized out>) at /home/mgmt/Documents/Projects/libtins/src/eapol.cpp:68
#7  0x00007ffff7b97c5a in Tins::SNAP::SNAP (this=0x55555576f1f0, buffer=0x55555576f17a "\252\252\003", total_sz=12) at /home/mgmt/Documents/Projects/libtins/src/snap.cpp:56
#8  0x00007ffff7ba3f61 in Tins::Dot11Data::Dot11Data (this=0x55555576f190, buffer=<optimized out>, total_sz=<optimized out>) at /home/mgmt/Documents/Projects/libtins/src/dot11/dot11_data.cpp:56
#9  0x00007ffff7ba2b66 in Tins::Dot11::from_bytes (buffer=buffer@entry=0x55555576f162 "\b\t:\001h\034\242\002t:\314)\365MK\002h\034\242\002t:P\267\252\252\003", total_sz=total_sz@entry=36)
    at /home/mgmt/Documents/Projects/libtins/src/dot11/dot11_base.cpp:258
#10 0x00007ffff7b9452e in Tins::RadioTap::RadioTap (this=0x7fffffffe1d0, buffer=<optimized out>, total_sz=36) at /home/mgmt/Documents/Projects/libtins/src/radiotap.cpp:114
#11 0x00005555555576a6 in Tins::RawPDU::to<Tins::RadioTap> (this=0x55555576f110) at /usr/local/include/tins/rawpdu.h:194
#12 0x0000555555556a31 in handler (pdu=...) at test.cpp:24
#13 0x0000555555556f05 in main () at test.cpp:86

All the other packets seem to fail once it attempts to determine whether it is RSNEAPOL or RC4EAPOL.

eapol_malformed_libtins.pcap.zip

mfontanini commented 7 years ago

Thanks, I'll look into this later today for sure.

mfontanini commented 7 years ago

It seems like the implementation of EAPOL in the library doesn't take into account all possible packet types. I'll work on this in a few days as it's not a trivial change (e.g. there's no support for parsing the EAP part of the frames).

christophert commented 6 years ago

Any update to this?

mfontanini commented 6 years ago

No, I'll be having some busy next couple of weeks and given this is a decent amount of work, I don't think I'll be able to sit down and work on it until after that. Sorry for the inconvenience.

christophert commented 6 years ago

Additionally, I've noticed that the EAPOL implementation does not take into account the EAP Type (Key (3) or EAP Packet (0)) when determining RSN/RC4 EAPOL.

For example, in this capture, frame 38 is an EAP WPS Request (802.1x Type 0, EAP Code 1, EAP Type 254 (Expanded Type)) and frame 39 is an EAP WPS Response (802.1x Type 0, EAP Code 2, EAP Type 254) however it is parsed as a RC4 and RSN EAPOL packet. It seems that it should check for EAP Type 3 before parsing into RC4/RSN EAPOL?

I am using this Wireshark example capture: https://wiki.wireshark.org/SampleCaptures?action=AttachFile&do=get&target=wpsdata.cap

mfontanini commented 6 years ago

Yeah, the implementation surely has some issues. I haven't forgotten about this, I just haven't had time to sit down and fix it. I should have some this week so I'll try to have a look at it.

christophert commented 6 years ago

Is it possible to pull the byte payload of the layer once it's parsed at the RSN/RC4 EAPOL layer? Or would we just have to pull the full raw PDU?

mfontanini commented 6 years ago

You'd have to get the full raw PDU. Once the layer is parsed, the raw data is gone.

christophert commented 6 years ago

Any progress on this issue?

mfontanini commented 6 years ago

No updates on this and I don't have much free time so I'm not sure when I'll be able to work on it. Sorry!

christophert commented 6 years ago

I would like to put some effort into solving this issue but am not sure how to properly implement this since there doesn't seem to be much documentation on implementing this type of protocol. Are there any resources that I can look at to kickstart that?

mfontanini commented 6 years ago

I don't think there's any documentation on how to do that but it shouldn't be hard to infer from existing protocols. You could grab some small one like UDP for example to get an idea.

AntiMatterDynamite commented 5 years ago

also having this issue , probably will work to fix this in the next few days, im planning to completely overhaul all the existing code for eapol so im not sure if anyone will want it