Fedora has issued an advisory on November 5: https://lists.fedoraproject.org/pipermail/package-announce/2014-November/143595.html The issues are fixed in 1.2 RC1, which Fedora updated to in this commit: http://pkgs.fedoraproject.org/cgit/aircrack-ng.git/commit/?id=b61928590565adf15921786913b06d4fa803f744 Mageia 3 and Mageia 4 are also affected. Reproducible: Steps to Reproduce:
Whiteboard: (none) => MGA4TOO, MGA3TOO
Looking at the code, CVE-2014-8321 doesn't affect 1.1. The patches for the other CVEs linked from the RedHat bug apply cleanly to 1.1. Freeze push requested for Cauldron for 1.2-rc1. Patched package uploaded for Mageia 3 and Mageia 4. Advisory: ======================== Updated aircrack-ng package fixes security vulnerabilities: A length parameter inconsistency in Aircrack-ng before 1.2-rc1 at aireplay tcp_test() which may lead to remote code execution (CVE-2014-8322). A missing check for data format in Aircrack-ng before 1.2-rc1 at buddy-ng which may lead to denial of service (CVE-2014-8323). A missing check for invalid values in Aircrack-ng before 1.2-rc1 at airserv-ng net_get() which may lead to denial of service (CVE-2014-8324). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-8322 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-8323 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-8324 https://www.obrela.com/home/security-labs/advisories/osi-advisory-osi-1401/ https://lists.fedoraproject.org/pipermail/package-announce/2014-November/143595.html ======================== Updated packages in core/updates_testing: ======================== aircrack-ng-1.1-5.2.mga3 aircrack-ng-1.1-7.1.mga4 from SRPMS: aircrack-ng-1.1-5.2.mga3.src.rpm aircrack-ng-1.1-7.1.mga4.src.rpm
CC: (none) => cvargasWhiteboard: MGA4TOO, MGA3TOO => MGA3TOOAssignee: cvargas => qa-bugsVersion: Cauldron => 4
I don't know if there are any PoCs for the CVEs. Claire previously used this tutorial to test this: http://www.aircrack-ng.org/doku.php?id=injection_test
Whiteboard: MGA3TOO => MGA3TOO has_procedure
If anyone knows anything about this tool, please feel free to test it or chime in. I tried to follow the directions in Comment 2 on my laptop and this update (specifically the CVE-2014-8324 change) appears to have broken the Airserv-ng test (the last test) listed on that page. I rebuilt the 1.2-rc1 from Cauldron on Mageia 4 and got the same results there. This may need more work from upstream. Adding the feedback marker for now.
Whiteboard: MGA3TOO has_procedure => MGA3TOO has_procedure feedback
Upstream bug filed here: http://trac.aircrack-ng.org/ticket/1545
Cancelling this update for Mageia 3 due to EOL. The bug I filed has received no response. The response I received on IRC on Saturday when I initially tried to report this was antagonistic to say the least. I'm more of a mind to just drop this package and forget about this.
Whiteboard: MGA3TOO has_procedure feedback => has_procedure feedback
Assigning back to Cesar.
Assignee: qa-bugs => cvargasCC: (none) => qa-bugs
Thank you very much, I'll take care
CC: (none) => juan.baptiste
I'll have a look to the test too. I would like to stress that the package is more than injecting, it is useful for various other tasks as monitoring etc... So, even if injection is broken by the CVE fix, this package should not be dropped. That's just a normal bug now. cheers, chris.
CC: (none) => dirteat
What do you mean by "normal bug"?
CC: (none) => mageia
Hi guys, just tested cauldron version, 1.2 RC1, injection works fine on my laptop :) The only issue is the tutorial to test injection which is a bit too short, and these days, access points are hidden as well. If someone can valid this for mga4, that bug is solved. Here a detailled tutorial to test injection that worked for me: cheers, chris, ------------------------------------------------------ 1) get the name of your wireless interface: ifconfig -a mine is wlp1s0 (wlan0 names are no longer in use with recent udev) 2) stop any wireless connections: ifdown wlp1s0 3) kill any progs accessing the interface: To get the list of progs enter: airmon-ng check wlp1s0 in my case, it returns: PID Name 23609 avahi-daemon 23610 avahi-daemon 25087 wpa_supplicant 25089 ifplugd Process with PID 25087 (wpa_supplicant) is running on interface wlp1s0 Process with PID 25089 (ifplugd) is running on interface wlp1s0 For avahi, do: systemctl stop avahi-daemon.service For the others: kill 25087 25089 Check again: airmon-ng check wlp1s0 should return nothing. 4) Switch the interface into monitoring mode: airmon-ng start wlp1s0 you see: Interface Chipset Driver wlp1s0 Intel 6235 iwlwifi - [phy0] (monitor mode enabled on mon0) You can check that a new interface has been created ifconfig -a should display mon0 in addition to wlp1s0 and others, PS: Enter the command airmon-ng start wlp1s0 only once otherwise you are adding as much monX interfaces (in case of mistakes, close them with airmon-ng stop monX) 5) Now, examine what your interface is receiving: airodump-ng mon0 On the countryside, there is only my router (in cities, try to find yours among the long list of things entering your place) You get something like this: BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID D0:AE:EC:2A:71:88 -48 110 143 0 7 54e. WPA2 CCMP PSK MYNAME Write down somewhere the: BSSID CH ESSID here my router is broadcasting on channel 7 6) Now, try injection on your access point with: aireplay-ng --test -e MYNAME -a D0:AE:EC:2A:71:88 wlp1s0 Most likely this will fail with an explicit message like that: 17:39:06 Waiting for beacon frame (BSSID: D0:AE:EC:2A:71:88) on channel 8 17:39:06 wlp1s0 is on channel 8, but the AP uses channel 7 7) Change the injection channel of your interface to 7 with this: airmon-ng stop mon0 airmon-ng start wlp1s0 7 8) Try again injecting: aireplay-ng --test -e MYNAME -a D0:AE:EC:2A:71:88 wlp1s0 17:42:00 Waiting for beacon frame (BSSID: D0:AE:EC:2A:71:88 ) on channel 7 17:42:00 Trying broadcast probe requests... 17:42:00 Injection is working! 17:42:02 Found 1 AP 17:42:02 Trying directed probe requests... 17:42:02 D0:AE:EC:2A:71:88 - channel: 7 - 'MYNAME' 17:42:02 Ping (min/avg/max): 0.853ms/4.515ms/34.638ms Power: -46.90 17:42:02 30/30: 100%
Should this be assigned to QA?
(In reply to Sander Lepik from comment #11) > Should this be assigned to QA? Nope, I tested it and one of the CVE patches broke it.
Broke what exactly? I thouht it was injection, but as my test showed above, injection is working fine!
(In reply to Chris Denice from comment #13) > Broke what exactly? > I thouht it was injection, but as my test showed above, injection is working > fine! Airserv-ng is broken. See the previous comments.
Ok, I'll have a closer look to airserv-ng specically. Why not opening a "normal" bug report for airserver-ng and goes on with this security update? As far as I see, a "minor" feature of this package is broken and there is no any longer a security issue.
(In reply to Chris Denice from comment #15) > Ok, I'll have a closer look to airserv-ng specically. > > Why not opening a "normal" bug report for airserver-ng and goes on with this > security update? As far as I see, a "minor" feature of this package is > broken and there is no any longer a security issue. I opened a bug upstream. As far as our package goes, it's a regression.
I submitted aircrack-ng-1.2-0.rc1.2.mga5 which allows for zero values of "plen" in net_get() calls. That fixes the issue with airserver. I posted it upstream as well to check if the security issue is not reopened in that case. Negative values are still asserted and aborted, so the security fix should still be ok.
aircrack-ng-1.2-0.rc1.2.mga5 submitted by Chris Denice works well, the bug that had corrected. [root@VaCi0 ~]# aireplay-ng -9 127.0.0.1:666 14:44:08 Testing connection to injection device 127.0.0.1:666 14:44:08 TCP connection successful 14:44:08 airserv-ng found 14:44:08 ping 127.0.0.1:666 (min/avg/max): 0.171ms/0.248ms/0.481ms Connecting to 127.0.0.1 port 666... Connection successful 14:44:08 Trying broadcast probe requests... 14:44:08 Injection is working! 14:44:12 Found 1 AP 14:44:12 Trying directed probe requests... 14:44:12 C8:64:C7:60:00:00 - channel: 8 - 'XXXXXXXXX' 14:44:13 Ping (min/avg/max): 0.281ms/30.679ms/40.428ms Power: -68.47 14:44:13 30/30: 100%
OK, I added Chris's patch to fix the assertion error to the Mageia 4 update. This would have been a lot easier if upstream had been cooperative. Advisory: ======================== Updated aircrack-ng package fixes security vulnerabilities: A length parameter inconsistency in Aircrack-ng before 1.2-rc1 at aireplay tcp_test() which may lead to remote code execution (CVE-2014-8322). A missing check for data format in Aircrack-ng before 1.2-rc1 at buddy-ng which may lead to denial of service (CVE-2014-8323). A missing check for invalid values in Aircrack-ng before 1.2-rc1 at airserv-ng net_get() which may lead to denial of service (CVE-2014-8324). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-8322 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-8323 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-8324 https://www.obrela.com/home/security-labs/advisories/osi-advisory-osi-1401/ https://lists.fedoraproject.org/pipermail/package-announce/2014-November/143595.html ======================== Updated packages in core/updates_testing: ======================== aircrack-ng-1.1-7.1.mga4 from aircrack-ng-1.1-7.2.mga4.src.rpm
Whiteboard: has_procedure feedback => has_procedureCC: qa-bugs => (none)Assignee: cvargas => qa-bugs
Testing complete mga4 32 with a usb wifi adapter (wlan0) Not all interfaces are supported but I know this one is from previous testing. Verified airserv-ng is still ok # airserv-ng -d wlan0 -c 1 In a separate terminal.. # aireplay-ng -9 127.0.0.1:666 13:33:05 Testing connection to injection device 127.0.0.1:666 13:33:05 TCP connection successful 13:33:05 airserv-ng found 13:33:05 ping 127.0.0.1:666 (min/avg/max): 0.111ms/0.205ms/0.348ms Connecting to 127.0.0.1 port 666... Connection successful 13:33:05 Trying broadcast probe requests... 13:33:09 No Answer... 13:33:09 Found 3 APs 13:33:09 Trying directed probe requests... ...etc Took the rest from https://bugs.mageia.org/show_bug.cgi?id=11402#c1 # airmon-ng start wlan0 Verified it created mon0 interface # iwconfig Tested aireplay with the interface.. # aireplay-ng -9 mon0 Removed the interface # airmon-ng stop mon0
Whiteboard: has_procedure => has_procedure mga4-32-ok
MGA4-64 on HP Probook 6555b No installation issues. My router is at channel 3. Followed testing as Comment 10 and got at CLI: aireplay-ng --test -e <ESSID> -a <BSSID> mon0 15:54:44 Waiting for beacon frame (BSSID: 11:11:11:11:11:11) on channel 10 15:54:44 mon0 is on channel 10, but the AP uses channel 3 then airmon-ng stop mon0 airmon-ng start wlp7s0 3 and then aireplay-ng --test -e <ESSID> -a <BSSID> wlp7s0 16:02:07 Waiting for beacon frame (BSSID: 11:11:11:11:11:1) on channel 3 16:02:07 Trying broadcast probe requests... 16:02:07 Injection is working! 16:02:09 Found 1 AP 16:02:09 Trying directed probe requests... 16:02:09 11:11:11:11:11:11 - channel: 3 - '<ESSID>' 16:02:09 Ping (min/avg/max): 1.429ms/13.342ms/27.457ms Power: -35.80 16:02:09 30/30: 100% Which is the sama as in Comment 10.
Whiteboard: has_procedure mga4-32-ok => has_procedure MGA4-32-OK MGA4-64-OKCC: (none) => herman.viaene
Validating. Advisory uploaded. Please push to 4 updates Thanks
CC: (none) => sysadmin-bugsWhiteboard: has_procedure MGA4-32-OK MGA4-64-OK => has_procedure advisory MGA4-32-OK MGA4-64-OKKeywords: (none) => validated_update
An update for this issue has been pushed to Mageia Updates repository. http://advisories.mageia.org/MGASA-2015-0035.html
Status: NEW => RESOLVEDResolution: (none) => FIXED