Wireshark Pick its Teeth of Security Problems
It seems that several vulnerabilities which affected Wireshark version 1.0.3 (and older versions down to 0.10.3) were fixed this week when the software developer released v. 1.0.4
Wireshark is a network protocol analyzer software that can be used for several tasks: troubleshooting, analysis, development and education. The Wireshark project was launched 10 years ago, back in 1998, and in all this time it has not only managed to amount a considerable gathering of contributors, but also managed to become an industry standard.
One of the main issues that needed addressing was the fact that Wireshark would crash when inspecting certain packets. If Wireshark crashes (or is intentionally crashed) while it monitors a network, this pretty much leaves the door wide open for an attacker. It would also be very difficult for forensic annalists to gather relevant data about the manner in which the attack was conducted.
How could someone intentionality crash Wireshark? There are two viable options; one would be to get a user on the network to try and read a malformed packet trace file. The other option would be to inject malformed packets into the network. Not only will the attacker be successful, it will also be easier for him to cover his tracks. Going undetected is the goal of every attack, isn't it?
Here is a list of all the vulnerabilities which until version 1.0.4 could have caused Wireshark to crash: Q.931 dissector error, Bluetooth RFCOMM and USB dissector uninitialized data structures, Bluetooth ACL dissector error. There was also a bug which caused the software to abort whenever Tamos CommView capture files were read – this has also been fixed withing Wireshark 1.0.4. A total of 14 bugs have been fixed.
It must be noted that there are no other workarounds for the issues that v. 1.0.4 addresses. If you want to fix all these bugs, the only viable option is to upgrade.
Wireshark is a network protocol analyzer software that can be used for several tasks: troubleshooting, analysis, development and education. The Wireshark project was launched 10 years ago, back in 1998, and in all this time it has not only managed to amount a considerable gathering of contributors, but also managed to become an industry standard.
One of the main issues that needed addressing was the fact that Wireshark would crash when inspecting certain packets. If Wireshark crashes (or is intentionally crashed) while it monitors a network, this pretty much leaves the door wide open for an attacker. It would also be very difficult for forensic annalists to gather relevant data about the manner in which the attack was conducted.
How could someone intentionality crash Wireshark? There are two viable options; one would be to get a user on the network to try and read a malformed packet trace file. The other option would be to inject malformed packets into the network. Not only will the attacker be successful, it will also be easier for him to cover his tracks. Going undetected is the goal of every attack, isn't it?
Here is a list of all the vulnerabilities which until version 1.0.4 could have caused Wireshark to crash: Q.931 dissector error, Bluetooth RFCOMM and USB dissector uninitialized data structures, Bluetooth ACL dissector error. There was also a bug which caused the software to abort whenever Tamos CommView capture files were read – this has also been fixed withing Wireshark 1.0.4. A total of 14 bugs have been fixed.
It must be noted that there are no other workarounds for the issues that v. 1.0.4 addresses. If you want to fix all these bugs, the only viable option is to upgrade.
