Πιθανό πρόβλημα (privilege escalation) σε Debian (ubuntu)

[orgixmh]

Καλησπέρα στους Devs του insomnia, 
γράφω μία εφαρμογή για Ubuntu (γενικότερα Debian) που εμφανίζει στατιστικά χρήσης (networks/cpu/ram/hdd/temps).
Σύντομα θα ανοίξω το repo στο git μιας και θα είναι  opensource και free.
Ο στόχος  είναι να μεταφέρω το iStat που υπάρχει στο MacOS στα ubuntu και σιγά σιγά και στις υπόλοιπες διανομές. 
Μέχρι στιγμής έχω γράψει τον indicator για τον Gnome, το παράθυρο με τα στατιστικά χρήσης σε electron και ο μοναδικός αισθητήρας που έχω στην εφαρμογή είναι το nethogs όπου το τροποποίησα ώστε να μου στέλνει τα data μέσω web socket στο electron. 

Το πρόβλημα που αντιμετωπίζω είναι το εξής:
Το nethogs χρειάζεται sudo για να sniffαρει το δίκτυο, αντί για του δώσω superuser perms του δίνω τα δικαιώματα που χρειάζεται μέσω του setcap κατά την πρώτη εκκίνηση του προγράμματος όπως φαίνεται και στο video. 

Βάση των παραπάνω φοβάμαι την περίπτωση που κάποιος βρει τρόπο να πάρει sudo perms μέσω της εφαρμογής μου δεδομένου ότι η εφαρμογή μου τρέχει με user perms αλλά ο sensor τρέχει με κάποια super user perms και αυτά τα 2 επικοινωνούν μέσω socket. Προς το παρών έχω κόψει την δυνατότητα αμφίδρομης επικοινωνίας μεταξύ σένσορα και εφαρμογής, ο sensor δεν ακούει καν στα εισερχόμενα και το μόνο που κάνει είναι να στέλνει data στο socket.
Είναι αρκετό το παραπάνω για να αποτρέψει privilege escalation?

Ένα demo του app μπορείτε να δείτε εδώ: 

 

[pmav99]

Θεωρητικά, δεν χρειάζεσαι sudo για να πάρεις τα στατιστικά του network. Μπορείς να τα διαβάσεις κατευθείαν από το /proc ή/και το /sys. Πχ το

cat /proc/net/dev

θα σου δώσει στατιστικά ανα NIC (Network InterfaCe)

Την ίδια πληροφορία νομίζω μπορείς να πάρεις και από το

cat /sys/class/net/wlan0/statistics/*   # change wlan0 with the name of your NIC

όπου είναι μάλλον πιο εύκολο να παρσάρεις το output.

Αφού θέλεις στατιστικά και ανά process, γίνεται να τα πάρεις πάλι μέσω του

cat /proc/PID/net/netstats   # Replace PID with the actual Process ID

(δες πχ εδώ), αυτό είναι που κάνει και το nethogs άλλωστε, αλλά θα είναι αρκετή μανούρα να το κάνεις μόνος σου οπότε το να χρησιμοποιήσεις κάποια εφαρμογή/βιβλιοθήκη που το κάνει ήδη είναι η λογική επιλογή.

On 11/05/2021 at 22:43, orgixmh said:

Το nethogs χρειάζεται sudo για να sniffαρει το δίκτυο, αντί για του δώσω superuser perms του δίνω τα δικαιώματα που χρειάζεται μέσω του setcap κατά την πρώτη εκκίνηση του προγράμματος όπως φαίνεται και στο video. 

Αν κάνεις setcap στο binary του nethogs, τότε οποιοσδήποτε μπορεί να τρέξει το nethogs χωρίς sudo σωστά; Αν ναι, τότε νομίζω ότι δεν είναι το καλύτερο approach. Προσωπικά, θα με ενοχλούσε αν η εγκατάσταση ενός tool αλλάζε τα permissions ενός άλλου tool απλά με ένα pop-up που δεν εξηγεί τα security implications.

Μια άλλη εναλλακτική είναι να χρησιμοποιήσεις το systemd για να δώσεις τα capabilities που χρειάζεσαι η εφαρμογή σου μέσω του AmbientCapabilities. Τσέκαρε εδώ που τα έχει γράψει ο @asfodelus για λεπτομέρειες: https://cerebrux.net/2020/08/27/capabilities-sudo-suid/

 

[orgixmh]

47 λεπτά πριν, pmav99 είπε

Θεωρητικά, δεν χρειάζεσαι sudo για να πάρεις τα στατιστικά του network. Μπορείς να τα διαβάσεις κατευθείαν από το /proc ή/και το /sys. Πχ το

cat /proc/net/dev

θα σου δώσει στατιστικά ανα NIC (Network InterfaCe)

Την ίδια πληροφορία νομίζω μπορείς να πάρεις και από το

cat /sys/class/net/wlan0/statistics/*   # change wlan0 with the name of your NIC

όπου είναι μάλλον πιο εύκολο να παρσάρεις το output.

Αφού θέλεις στατιστικά και ανά process, γίνεται να τα πάρεις πάλι μέσω του

cat /proc/PID/net/netstats   # Replace PID with the actual Process ID

(δες πχ εδώ), αυτό είναι που κάνει και το nethogs άλλωστε, αλλά θα είναι αρκετή μανούρα να το κάνεις μόνος σου οπότε το να χρησιμοποιήσεις κάποια εφαρμογή/βιβλιοθήκη που το κάνει ήδη είναι η λογική επιλογή.

Αν κάνεις setcap στο binary του nethogs, τότε οποιοσδήποτε μπορεί να τρέξει το nethogs χωρίς sudo σωστά; Αν ναι, τότε νομίζω ότι δεν είναι το καλύτερο approach. Προσωπικά, θα με ενοχλούσε αν η εγκατάσταση ενός tool αλλάζε τα permissions ενός άλλου tool απλά με ένα pop-up που δεν εξηγεί τα security implications.

Μια άλλη εναλλακτική είναι να χρησιμοποιήσεις το systemd για να δώσεις τα capabilities που χρειάζεσαι η εφαρμογή σου μέσω του AmbientCapabilities. Τσέκαρε εδώ που τα έχει γράψει ο @asfodelus για λεπτομέρειες: https://cerebrux.net/2020/08/27/capabilities-sudo-suid/

 

Καταρχάς ευχαριστώ για την τρομερά αναλυτική απάντηση, σχετικά με το nethogs τρέχει δίχως sudo όπως καλά κατάλαβες αλλά δεν έχει sudo access, στην ουσία είναι πάνω κάτω  το ίδιο με την πατέντα με το euid και το uid, αυτό λέει και ο asfodelus στο τέλος "Αλλά υπάρχει και ένας πιο απλός τρόπος με την χρήση των capabilities." 

Με το setcap το nethogs δεν παίρνει sudo access, απλός παίρνει πρόσβαση σε συγκεκριμένα capabilities.
τα capabilities είναι αυτά τα 2: cap_net_admin cap_net_raw

Αυτό που με προβληματίζει είναι το εξής: αν υποθέσουμε ότι με κάποιο τρόπο μέσω του socket ο επιτιθέμενος καταφέρνει να κάνει buffer overflow και να φορτώσει κώδικα στην μνήμη τότε αυτός ο κώδικας υποθετικά θα έχει τα παραπάνω caps, θα έχει πρόσβαση στην κίνηση του δικτύου και με λίγη τύχη θα μπορέσει ίσως να σνιφάρει data.

Πάνω σε αυτή την λογική έκοψα κάθε εισερχόμενο στο socket, το nethogs έχει την ικανότητα πλέον να στέλνει data στο socket αλλά όχι να λαμβάνει όμως δεν μπορώ να είμαι σίγουρος αν αυτό είναι αρκετό και όσο και αν προσπάθησα να το hackaρω ο ίδιος δεν κατάφερα τίποτα μιας και οι γνώσεις μου στο hacking είναι σχεδόν μηδαμινές.

Η ιδέα με το netstats μου άρεσε και δουλεύει ρολόι αλλά χρειάζεται δουλειά μερικών ημερών για να γίνει sensor.

 

Επεξ/σία 14 Μαΐου 2021 από orgixmh

[asfodelus]

Είναι μια καλή σχεδίαση. Θα προτιμούσα την χρήση του dBus για την επικοινωνία, αντί για ένα καθαρό socket. Έτσι πχ θα μπορούσε ποιο εύκολα κάποιος τρίτος  να τους κάνει χρήση, ενώ έχεις και την δυνατότητα χρήσης εξωτερικών μηχανισμών ασφαλείας με το polkit. Αλλά πρόσεξε μην πάθεις paralisys by analysis. Γράψε κάτι να δουλεύει, μετά να δουλεύει σωστά και μετά να δουλεύει με ασφάλεια. Και αν έχεις σχεδιάσει σωστά την εφαρμογή με layers το πως σου έρχονται τα δεδομένα θα πρέπει είναι εντελώς αδιάφορο στο Presentation Layer. 

Κάποια άλλα πραγματάκια που έχω γράψει και ίσως φανούν χρήσιμα:

https://linux-user.gr/t/asfaleia-sta-akra-hardening-mias-yphresias-me-to-systemd/2303

https://linux-user.gr/t/periorismos-toy-ti-mporei-na-kanei-mia-efarmogh-chwris-kwdika/2243

και όλο λέω να γράψω κατι για το polkit και όλο το αναβάλω. Ίσως τις επόμενες μέρες. Αλλά spoiler alert δεν είμαι κανένας guru, και σίγουρα θα βρεις κάποιους εδώ μέσα έτοιμους να με αποκαλέσουν άσχετο και κάποιους άλλους με περισσότερες γνώσεις στο αντικείμενο. Έχουν κάποιο δίκιο. Απλά γράφω και μεταφέρω ότι ανακαλύπτω, με την αμυδρή ελπίδα πως θα τα διαβάσει κάποιος ποιο σχετικός και θα βρει τον χρόνο να με διορθώσει. Έτσι θα του κλεψω την γνώση και την εμπειρία χεχεχε. Οπότε ένα development journal της πορείας σου θα είναι χρήσιμο σε όλους και ποιο πολύ σε μένα, αν θέλεις να μπεις σε αυτόν το κόπο

[pmav99]

αυτό που λέω είναι ότι όταν κάνω `sudo apt install nethogs` το nethogs εγκαθίσταται με συγκεκριμένα capabilities. Οι debian/ubuntu maintainers θα μπορούσαν να προσθέτουν capabilities κατά την εγκατάσταση του nethogs αλλά για δικούς τους λόγους δεν το κάνουν. Όταν τρέχει τώρα η εφαρμογή σου με ρωτά αν θέλω να  εγκαταστήσω κάτι με sudo (που ως χρήστης δεν ξέρω τι είναι αυτό) και μετά, behind the scenes, εικάζω ότι εκτελείς κάτι τέτοιο

sudo setcap cap_net_admin,cap_net_raw+ep /usr/bin/nethogs

H παραπάνω εντολή αλλάζει τα capabilities του binary του nethogs.

Το ερώτημα είναι τι δουλειά έχει το δικό σου application να αλλάξει τα capabilities ενός binary που εγκαθίσταται με διαφορετικό πακέτο;

BTW, τι συμβαίνει αν ο χρήστης πατήσει "Νο" στο popup?

[asfodelus]

Στην μεσημεριανή μου βόλτα αφήνω το μυαλό μου να κάνει ένα εσωτερικό διάλογο και του έθεσα το πρόβλημα της αρχιτεκτονικής. Μεταφέρω την κουβέντα εδώ για ιδέες και brainstorming. Ένα πρώτο πρόβλημα είναι πως η μέτρηση από μόνη της  δεν αρκεί. Μια μέτρηση χωρίς το απαραίτητο calibration και quirks δεν έχει νόημα. Και δεν θέλεις να κάνεις εσύ αυτή την δουλεία διαβάζοντας απευθείας το /sys (ή μπορεί και να είναι ήδη καλιμπραρισμένες εκεί οι τιμές -- δεν ξέρω πρέπει να δω κώδικα). Επίσης δεν είναι τόσο σταθερό. Πριν λίγες μέρες έγραψα ένα conky και ακολούθησα αυτόν τον δρόμο. Αλλά άλλαξα τα modules και μετά την πρώτη επανεκκίνηση διάβαζα  άλλα πράγματα). Επίσης δεν μπορούσα να πάρω τα Watts γιατί η τιμή ήθελε κάποιο μετασχηματισμό, οπότε εκεί πήγα με το sensors και ενα επιπλέον εξωτερικό process. 

Επίσης δεν ξέρω τι use case θέλεις: Να βλέπεις μια temporal εικόνα όπως πχ κάτι σαν το `watch -d sensors` ή την εξέλιξη στο χρόνο; Για ένα υπολογιστή ή για πολλούς; Σίγουρα πάντως θα πρέπει να διαχωρίσεις την συλλογή από το data aquisation και το storage. Στην δεύτερη περίπτωση θα χρησιμοποιούσα μια time series database όπως το RRDTool ή κάτι ποιο enterprise όπως InfluxDb ή Promrtheus. Προσθέτεις και ένα graphana στο electron και σου πέφτουν τα σαγόνια κάτω  (μεταξύ άλλων και απο την μνήμη που θα χρησιμοποιεί)

Στην πρώτη περίπτωση θα πατούσα σε ώμους γιγάντων. Με το dbus δεν έχεις να ανησυχείς για την ασφάλεια, με το systemd δεν έχεις να ανησυχείς πως θα τρέχει κάτι που δεν θέλεις αν το κάνεις dbus activated.  Θα έπαιρνα τον κώδικα του sensors και θα το έκανα να στέλνει τα δεδομένα μέσα από το dbus. Και έτσι η πολύ δουλεία θα έχει φύγει απο τα χέρια μου. Μένει να δω πως θα είναι το API αν θα κάνεις polling ή αν θα είναι event based, πως θα δηλώνεις στην δεύτερη περίπτωση πως δεν το θέλεις πλέον (και τι θα συμβεί αν δυο το χρησιμοποιούν; Αν οι clients θέλουν διαφορετικά στοιχεία; Είναι ποιο απλό να στέλνεις τα πάντα ή αυτό είναι βαρύ σε χρόνο ή υπολογισμους;)

Υπάρχουν πολλά εργαλεία που μας παρέχει ο πυρήνας και τα κάνει προσιτά το systemd και είναι κρίμα να μην τα χρησιμοποιήσουμε. Και το μοντέρνο Linux έχει πολλές δυνατότητες που είναι κρίμα να μην χρησιμοποιηθούν. Αν και υπάρχει ένας μεγάλος κίνδυνος: να μην τρέξει στο 0.01% των εγκαταστάσεων με διανομές σαν αυτές που προτείνει το γνωστό τρολάκι του insomnia. Ας μείνει στο POSIX του και στις χρεποδιανομές του να γουστάρει Πόποτα. 

[pmav99]

 

39 minutes ago, asfodelus said:

Στην δεύτερη περίπτωση θα χρησιμοποιούσα μια time series database όπως το RRDTool ή κάτι ποιο enterprise όπως InfluxDb ή Promrtheus. Προσθέτεις και ένα graphana στο electron και σου πέφτουν τα σαγόνια κάτω  (μεταξύ άλλων και απο την μνήμη που θα χρησιμοποιεί)

IMHV, αν είναι να βάλεις τόσο περίπλοκο stack βάζεις netdata και τελειώνεις https://github.com/netdata/netdata

[orgixmh]

5 ώρες πριν, pmav99 είπε

αυτό που λέω είναι ότι όταν κάνω `sudo apt install nethogs` το nethogs εγκαθίσταται με συγκεκριμένα capabilities. Οι debian/ubuntu maintainers θα μπορούσαν να προσθέτουν capabilities κατά την εγκατάσταση του nethogs αλλά για δικούς τους λόγους δεν το κάνουν. Όταν τρέχει τώρα η εφαρμογή σου με ρωτά αν θέλω να  εγκαταστήσω κάτι με sudo (που ως χρήστης δεν ξέρω τι είναι αυτό) και μετά, behind the scenes, εικάζω ότι εκτελείς κάτι τέτοιο

sudo setcap cap_net_admin,cap_net_raw+ep /usr/bin/nethogs

H παραπάνω εντολή αλλάζει τα capabilities του binary του nethogs.

Το ερώτημα είναι τι δουλειά έχει το δικό σου application να αλλάξει τα capabilities ενός binary που εγκαθίσταται με διαφορετικό πακέτο;

BTW, τι συμβαίνει αν ο χρήστης πατήσει "Νο" στο popup?

Δεν είναι πλέον ακριβώς το nethogs, είναι μία  edited version του nethogs όπου έχω αφαιρέσει το cui του (και ότι δεν χρειαζόμουν) και δεν κάνει install με το apt αλλά γίνεται compile μαζί με το app μου. Το binary βρίσκετε στο φάκελο του app μου /usr/lib/xstat/sensors/net και το όνομα πλέον δεν είναι nethogs αλλά nethogsws.

Αν ο χρήστης πατήσει το no τότε το πρόγραμμα  ανοίγει χωρίς τον network sensor μια και τα υπόλοιπα sensor δεν θα χρειάζονται sudo.

3 ώρες πριν, asfodelus είπε

Στην μεσημεριανή μου βόλτα αφήνω το μυαλό μου να κάνει ένα εσωτερικό διάλογο και του έθεσα το πρόβλημα της αρχιτεκτονικής. Μεταφέρω την κουβέντα εδώ για ιδέες και brainstorming. Ένα πρώτο πρόβλημα είναι πως η μέτρηση από μόνη της  δεν αρκεί. Μια μέτρηση χωρίς το απαραίτητο calibration και quirks δεν έχει νόημα. Και δεν θέλεις να κάνεις εσύ αυτή την δουλεία διαβάζοντας απευθείας το /sys (ή μπορεί και να είναι ήδη καλιμπραρισμένες εκεί οι τιμές -- δεν ξέρω πρέπει να δω κώδικα). Επίσης δεν είναι τόσο σταθερό. Πριν λίγες μέρες έγραψα ένα conky και ακολούθησα αυτόν τον δρόμο. Αλλά άλλαξα τα modules και μετά την πρώτη επανεκκίνηση διάβαζα  άλλα πράγματα). Επίσης δεν μπορούσα να πάρω τα Watts γιατί η τιμή ήθελε κάποιο μετασχηματισμό, οπότε εκεί πήγα με το sensors και ενα επιπλέον εξωτερικό process. 

Επίσης δεν ξέρω τι use case θέλεις: Να βλέπεις μια temporal εικόνα όπως πχ κάτι σαν το `watch -d sensors` ή την εξέλιξη στο χρόνο; Για ένα υπολογιστή ή για πολλούς; Σίγουρα πάντως θα πρέπει να διαχωρίσεις την συλλογή από το data aquisation και το storage. Στην δεύτερη περίπτωση θα χρησιμοποιούσα μια time series database όπως το RRDTool ή κάτι ποιο enterprise όπως InfluxDb ή Promrtheus. Προσθέτεις και ένα graphana στο electron και σου πέφτουν τα σαγόνια κάτω  (μεταξύ άλλων και απο την μνήμη που θα χρησιμοποιεί)

Στην πρώτη περίπτωση θα πατούσα σε ώμους γιγάντων. Με το dbus δεν έχεις να ανησυχείς για την ασφάλεια, με το systemd δεν έχεις να ανησυχείς πως θα τρέχει κάτι που δεν θέλεις αν το κάνεις dbus activated.  Θα έπαιρνα τον κώδικα του sensors και θα το έκανα να στέλνει τα δεδομένα μέσα από το dbus. Και έτσι η πολύ δουλεία θα έχει φύγει απο τα χέρια μου. Μένει να δω πως θα είναι το API αν θα κάνεις polling ή αν θα είναι event based, πως θα δηλώνεις στην δεύτερη περίπτωση πως δεν το θέλεις πλέον (και τι θα συμβεί αν δυο το χρησιμοποιούν; Αν οι clients θέλουν διαφορετικά στοιχεία; Είναι ποιο απλό να στέλνεις τα πάντα ή αυτό είναι βαρύ σε χρόνο ή υπολογισμους;)

Υπάρχουν πολλά εργαλεία που μας παρέχει ο πυρήνας και τα κάνει προσιτά το systemd και είναι κρίμα να μην τα χρησιμοποιήσουμε. Και το μοντέρνο Linux έχει πολλές δυνατότητες που είναι κρίμα να μην χρησιμοποιηθούν. Αν και υπάρχει ένας μεγάλος κίνδυνος: να μην τρέξει στο 0.01% των εγκαταστάσεων με διανομές σαν αυτές που προτείνει το γνωστό τρολάκι του insomnia. Ας μείνει στο POSIX του και στις χρεποδιανομές του να γουστάρει Πόποτα. 

Use case: ρίξτε μια ματιά στο istat, είναι app για να βλέπεις με ένα κλικ τι γίνεται στο σύστημα και να έχεις ένα log σε μορφή γραφήματος.
Ήμουν σε macos τα τελευταία 10+ χρόνια και εδώ και μερικές μέρες έφυγα στα ubuntu, το istat ήταν για εμένα το βασικότερο εργαλείο στα macos καθώς είχα net usage/temps/hdd usage στο topbar και με μία κλεφτή ματιά έβλεπα τι γίνεται χωρίς καν να πιάσω keyboard.
Στην ουσία αυτό που θέλω είναι ένα copy 1:1 του istat και να έχει την δυνατότητα για user made sensors πχ network monitoring μέσω snmp από το ρουτερ και γενικότερα θέλω ο user με λίγη js να μπορεί να γράψει ένα μικρό sensor για το οτιδίποτε, εγώ θέλω να του δίνω τα 5-6 βασικά σενσορ και μεθόδους σε js για να χτίσει εύκολα το μενού του στο xstats.  

Η εμπειρία μου σε linux based διανομές περιορίζεται στο open-wrt που το δουλεύω από εποχή lede αλλά είναι διανομή για routers και όχι για desktop και δεν είχε καν αυτό το systemd που υπάρχει στα ubuntu οπότε είμαι νουμπάκι στο θέμα και τις έννοιες systemd, ubus, gnomeJS, κτλ κτλ τις γνώρισα πριν μερικές μέρες που έφυγα σε ubuntu. 

Σχετικά με dbus κτλ σκοπός είναι να το μεταφέρω σε κάθε linux διανομή που έχει γραφικό περιβάλλον και δεν θέλω να έχω προβλήματα.

To graphana τα σπάει και ναι είναι στο πρόγραμμα μου να το κουμπώσω. σχετικά με την βάση έλεγα για sqlite 

Επεξ/σία 14 Μαΐου 2021 από orgixmh

[PC_MAGAS]

Πέρι network status μπορείς το App να είναι ένας DBus client:

https://liquidat.wordpress.com/2014/03/18/howto-using-dbus-to-query-status-information-from-networkmanager-or-others/