PDA

Επιστροφή στο Forum : Ευπάθεια των BCM43xx wifi chips της Broadcom, επηρέασε 1 δις συσκευές iOS και Android



nnn
29-07-17, 20:14
Στο συνέδριο Black Hat, ο ερευνητής Nitay Artenstein, επέδειξε μια proof of concept επίθεση εναντίον συσκευών με Android και iOS, που εκμεταλλεύεται κενό ασφαλείας του Wi-Fi chip BCM43xx της Broadcom.

Η ευπάθεια της οικογένειας BCM43xx, εξέθεσε σε κίνδυνο πάνω από 1 δις συσκευές (όλα τα iPhones από την έκδοση 5, την σειρά Nexus, Samsung Note και η σειρά Galaxy από το S3 ως το S8), μέχρι τις αρχές Ιουλίου που οι Google και Apple -που είχαν ειδοποιηθεί ιδιωτικά- έδωσαν patch που κλείνει το κενό το οποίο εκμεταλλεύεται την ευπάθεια των chips της Broadcom.



Although the flaw is now closed, the hack has important lessons as engineers continue their quest to secure mobile phones and other computing devices. Security protections such as address space layout randomization and data execution prevention have now become standard parts of the operating systems and apps. As a result, attackers have to work hard to exploit buffer overflows and other types of software vulnerabilities. That extra work largely makes self-replicating worms impossible. Artenstein's exploit, however, suggests that such worms are by no means impossible.

"This research is an attempt to demonstrate what such an attack, and such a bug, will look like," the researcher wrote in a detailed blog post. "Broadpwn is a fully remote attack against Broadcom’s BCM43xx family of Wi-Fi chipsets, which allows for code execution on the main application processor in both Android and iOS. It is based on an unusually powerful 0-day that allowed us to leverage it into a reliable, fully remote exploit."

In sharp contrast to the kernels in iOS and Android, the Broadcom chips Artenstein targeted aren't protected by ASLR or DEP. That meant he could reliably know where his malicious code would be loaded in chip memory so he could ensure it got executed. Additionally, he found a flaw across various chipset firmware versions that allowed his code to work universally rather than having to be customized for each firmware build. Making the attack even more potent, targets didn't have to connect to the attacker's Wi-Fi network. Simply having Wi-Fi turned on was sufficient to being hacked.

Artenstein said his attack worked on a wide range of phones, including all iPhones since the iPhone 5, Google's Nexus 5, 6, 6X and 6P models, Samsung Notes 3 devices, and Samsung Galaxy devices from S3 to S8. After he privately reported the flaw, Google and Apple released patches that closed the underlying vulnerability that made the attack possible. Because Wi-Fi chipsets in laptop and desktop computers have more limited access to the computer's networking functions, the researcher doesn't believe they are vulnerable to the same attack. While Artenstein's proof of concept didn't spread from the Wi-Fi chip to infect the phone's kernel, he said that additional step is well within the means of determined hackers.


Πηγή : Ars Technica (https://arstechnica.com/information-technology/2017/07/broadcom-chip-bug-opened-1-billion-phones-to-a-wi-fi-hopping-worm-attack/)

tsigarid
29-07-17, 23:23
Κλείσανε την τρύπα κρυφά, και μετά ανακοινώσαν. Πάλι καλά.

eyw
30-07-17, 12:52
ωραία, πάμε για την επόμενη ευπάθεια, ποιά εχει σειρά?

gst
30-07-17, 15:02
Σε ολα τα φτηνομοντελα η τρυπουλα...για αυτο σταυροκοπιομουν και νομισα οτι με θυμηθηκε η samsung με το note.....(android 4.4)

nnn
30-07-17, 15:23
Το θέμα είναι πόσα μοντέλα θα πάρουν το patch.

gst
30-07-17, 15:49
Το θέμα είναι πόσα μοντέλα θα πάρουν το patch.

και ποσοι θα το εγκαταστησουν,γιατι οτι "δουλευει"δεν το χαλαμε....

uncharted
30-07-17, 16:09
Το Nexus 5 πηρε update? Τρυπια αυτα τα binary blobs...

nnn
30-07-17, 16:12
Το Nexus 5 πηρε update? Τρυπια αυτα τα binary blobs...

Δεν ήρθε κάτι ακόμα...

manospcistas
30-07-17, 19:20
Προφανώς και κινητά όπως Galaxy S5 και S4 που έχω στην οικογένεια δεν θα πάρουν ποτέ ενημέρωση ασφαλείας, και δεν τα λες και για πέταμα.
Αυτό το θέμα με τα security patches πρέπει να αλλάξει κάποια στιγμή...

DaRk
30-07-17, 23:03
Στο Samsung J5 2016 σήμερα πάντως κατέβασα το July security update.

flamelab
31-07-17, 01:09
Τα iPhones στανταρ θα παρουν update (βλεπω οτι ειναι τα πιο "προσφατα"). Τα Galaxy S3 και S4 και τα Note counterparts αποκλειεται να παρουν update, το S5 επισης, αν και δινω λίγες πιθανοτητες.

ayan
31-07-17, 14:39
Το Nexus 5 πηρε update? Τρυπια αυτα τα binary blobs...

Όχι.. Το πρόβλημα αναφέρθηκε τον Απρίλιο 2017. Το Nexus 5 που είναι affected (chip model BCM4339) έχει να πάρει αναβάθμιση από τον Οκτώβριο 2016. Και μιλάμε για την Google, που συχνά κατηγορεί άλλες εταιρίες ότι δεν αντιδρούν εγκαίρως σε 0-day exploits.

uncharted
31-07-17, 15:33
Όχι.. Το πρόβλημα αναφέρθηκε τον Απρίλιο 2017. Το Nexus 5 που είναι affected (chip model BCM4339) έχει να πάρει αναβάθμιση από τον Οκτώβριο 2016. Και μιλάμε για την Google, που συχνά κατηγορεί άλλες εταιρίες ότι δεν αντιδρούν εγκαίρως σε 0-day exploits.
Καταλαβα, custom ROM και αν...

https://www.ifixit.com/Teardown/Nintendo+Switch+Teardown/78263

Broadcom/Cypress BCM4356 802.11ac 2×2 + Bluetooth 4.1 SoC

Λογικα επηρεαζεται και αυτο, ε?

zardoz
01-08-17, 19:08
To ΑΡΧΙΚΟ άρθρο του project zero βρίσκεται εδώ: https://blog.exodusintel.com/2017/07/26/broadpwn/

Για όσους βαριούνται να το διαβάσουν, εκμεταλεύεται 11 ΑΠΑΡΑΔΕΚΤΕΣ ΣΥΜΠΤΩΣΕΙΣ:

- Το ότι το συγκεκριμένο BCM chip έχει DEP αλλά όχι ASLR

- To ότι η μνήμη του είναι σε RWX state ολόκληρη !!!! οπότε ούτε DEP δεν έχει νόημα αφού μπορείς να γράψεις στο heap

- Τό ότι κάποιοι δημοσίεύσαν διαβαθμισμένο κώδικα σε ένα ξεχασμένο router VMG-1312 που τύχαινε να χρησιμοποιεί το εν λόγω chip

- To ότι μέσα στον εν λόγω κώδικα υπάρχει μια ρουτίνα wlc_bss_parse_wme_ie που αφορά το WMM και έχει ένα *malloc που δεν κάνει πριν buffer overrun check

- Το ότι το buffer overrun bug αυτό σου δίνει 211 όλόκληρα bytes να κάνεις overflow με δικό σου κώδικα

- Το ότι μπορείς να γράψεις εύκολα τέτοιο κώδικα μια και όλα τα BCM chips τρέχουν ARM Cortex-R4

- Το ότι κατά το WPA2 negotiation (πρίν το authenticate, στο σημείο που γίνεται η συνδιαλλαγή MAC/SSIDs μεταξύ AP και client) καλείται η ρουτίνα παραπάνω !! ΝΑΙ πρίν διευθετηθεί το authenticate!!!

- Το ότι, με το struct που περνούσαν στην μη-ελεγμένη ρουτίνα, κέρδισαν όχι μόνο 211 απροστάτευτα bytes, αλλά και έναν έξτρα write-one-dword ANYWHERE pointer !!!

- Το ότι σκίστηκαν και βρήκαν στο δημοσιευμένο source code ένα buffer με διεύθυνση σταθερή, ανεξαρτήτως firmware build !!!!!

- To ότι, σε 211 bytes έγραψαν έναν δικό τους pspoll_timer, τον έστειλαν στον "σταθερό" buffer παραπάνω κάνοντας ένα flood από προσπάθειες μέχρι να πιάσουν πρώτοι την κορυφή του buffer, και με τον write anywhere pointer παραπάνω, άλλαξαν το heap να τρέξει αυτό τον κώδικα στο επόμενο return.

- Και ο μικρος αυτός κώδικας αναζητούσε ελεύθερα στη μνήμη μια ρουτίνα wlc_recv (στην οποία παιρνούν μέσα-έξω όλα τα πακέτα) την οποία αν την αλλάξεις, μπορείς απλά να ψάχνεις για non-https κώδικα πχ top.location.href = http://www.adslgr.com και να τον αλλάζεις σε ότι θέλεις. Και ναι, η ρουτίνα ήταν ορατή στον "δημοσιευμένο" κώδικά, οπότε ήξεραν τι ψάχνουν.


Γι αυτό και δεν εμπιστεύεσαι κώδικα από ανθρώπους και - εκτός ότι αφήνεις τη μηχανή (DEP, ASLR) να κάνει σωστά (χμ όσο μπορεί) την δουλειά της, ΔΕΝ ΕΠΙΤΡΕΠΕΙΣ ΝΑ ΓΡΑΦΕΤΑΙ ΤΙΠΟΤΕ (εκτός data) ΣΤΟ HEAP ME
POINTERS - οι διευθυνεις στο heap μπαίνουν μόνο από το addressing της μηχανής. Από το 2001 το κυνηγάνε, ακόμα δεν το έκαναν υποχρεωτικό - τυχαίο? δε νομίζω.

Και ας μη ξεχνάμε υπάρχει ακόμα το https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-0561

uncharted
01-08-17, 19:48
@zardoz

Ενδιαφεροντα ολα αυτα που αναφερεις. Πιστευεις οτι ειναι εσκεμμενη "αβλεψια" λογω καποιας... τριγραμματης?

zardoz
01-08-17, 21:28
@zardoz

Ενδιαφεροντα ολα αυτα που αναφερεις. Πιστευεις οτι ειναι εσκεμμενη "αβλεψια" λογω καποιας... τριγραμματης?

Το συγκεκριμένο δε το θεωρώ σκόπιμο, είναι σειρά συμπτώσεων (σατανικών μεν, συμπτώσεων δε, σίγουρα απαράδεκτων).

Όμως. H αναζήτηση του exploit είναι (όπως όλες) ενδελεχής - κάτι σαν οι εν λόγω ερευνητές να χτίζουν "προφίλ" για
μελλοντική τους πρόσληψη από κάποιο φορέα cyber security ή από την τριγράμματη (αν δεν είναι ήδη υπάλληλοι σε κάποια).

Ακόμα χειρότερα, δημοσιεύουν αναλυτικά στο 100% το exploit, παραθέτουν και κώδικα στο πιάτο ώστε - κάποιοι τρίτοι να
τρέξουν να το υλοποιήσουν - αφήνοντας όσους δε μπορούν να ενημερώσουν στο έλεος του εξαποδώ.

Gianniskriti
01-08-17, 21:36
To ΑΡΧΙΚΟ άρθρο του project zero βρίσκεται εδώ: https://blog.exodusintel.com/2017/07/26/broadpwn/

Για όσους βαριούνται να το διαβάσουν, εκμεταλεύεται 11 ΑΠΑΡΑΔΕΚΤΕΣ ΣΥΜΠΤΩΣΕΙΣ:

- Το ότι το συγκεκριμένο BCM chip έχει DEP αλλά όχι ASLR

- To ότι η μνήμη του είναι σε RWX state ολόκληρη !!!! οπότε ούτε DEP δεν έχει νόημα αφού μπορείς να γράψεις στο heap

- Τό ότι κάποιοι δημοσίεύσαν διαβαθμισμένο κώδικα σε ένα ξεχασμένο router VMG-1312 που τύχαινε να χρησιμοποιεί το εν λόγω chip

- To ότι μέσα στον εν λόγω κώδικα υπάρχει μια ρουτίνα wlc_bss_parse_wme_ie που αφορά το WMM και έχει ένα *malloc που δεν κάνει πριν buffer overrun check

- Το ότι το buffer overrun bug αυτό σου δίνει 211 όλόκληρα bytes να κάνεις overflow με δικό σου κώδικα

- Το ότι μπορείς να γράψεις εύκολα τέτοιο κώδικα μια και όλα τα BCM chips τρέχουν ARM Cortex-R4

- Το ότι κατά το WPA2 negotiation (πρίν το authenticate, στο σημείο που γίνεται η συνδιαλλαγή MAC/SSIDs μεταξύ AP και client) καλείται η ρουτίνα παραπάνω !! ΝΑΙ πρίν διευθετηθεί το authenticate!!!

- Το ότι, με το struct που περνούσαν στην μη-ελεγμένη ρουτίνα, κέρδισαν όχι μόνο 211 απροστάτευτα bytes, αλλά και έναν έξτρα write-one-dword ANYWHERE pointer !!!

- Το ότι σκίστηκαν και βρήκαν στο δημοσιευμένο source code ένα buffer με διεύθυνση σταθερή, ανεξαρτήτως firmware build !!!!!

- To ότι, σε 211 bytes έγραψαν έναν δικό τους pspoll_timer, τον έστειλαν στον "σταθερό" buffer παραπάνω κάνοντας ένα flood από προσπάθειες μέχρι να πιάσουν πρώτοι την κορυφή του buffer, και με τον write anywhere pointer παραπάνω, άλλαξαν το heap να τρέξει αυτό τον κώδικα στο επόμενο return.

- Και ο μικρος αυτός κώδικας αναζητούσε ελεύθερα στη μνήμη μια ρουτίνα wlc_recv (στην οποία παιρνούν μέσα-έξω όλα τα πακέτα) την οποία αν την αλλάξεις, μπορείς απλά να ψάχνεις για non-https κώδικα πχ top.location.href = http://www.adslgr.com και να τον αλλάζεις σε ότι θέλεις. Και ναι, η ρουτίνα ήταν ορατή στον "δημοσιευμένο" κώδικά, οπότε ήξεραν τι ψάχνουν.


Γι αυτό και δεν εμπιστεύεσαι κώδικα από ανθρώπους και - εκτός ότι αφήνεις τη μηχανή (DEP, ASLR) να κάνει σωστά (χμ όσο μπορεί) την δουλειά της, ΔΕΝ ΕΠΙΤΡΕΠΕΙΣ ΝΑ ΓΡΑΦΕΤΑΙ ΤΙΠΟΤΕ (εκτός data) ΣΤΟ HEAP ME
POINTERS - οι διευθυνεις στο heap μπαίνουν μόνο από το addressing της μηχανής. Από το 2001 το κυνηγάνε, ακόμα δεν το έκαναν υποχρεωτικό - τυχαίο? δε νομίζω.

Και ας μη ξεχνάμε υπάρχει ακόμα το https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-0561

Μεγάλε μας έστειλες, αξιος

@ ADSLgr.com All rights reserved.