sudo Sicherheitslücke

pillow

Well-Known Member
hallo
möchte hier jemand etwas über die sudo Sicherheitslücke berichten , wie seid Ihr damit umgegangen?

golem
Bei der Sicherheitslücke handelt es sich um einen klassischen Speicherfehler (Heap-Based Buffer Overflow), der in der Programmiersprache C auftreten kann. Wie die Entdecker in ihrem Blog schreiben, wurde der betroffene Code erstmals im Juli 2011 in Sudo eingepflegt, also vor fast zehn Jahren. Die von dem Open-Source-Projekt veröffentlichten Versionen 1.8.2 bis 1.8.32p2 sowie 1.9.0 bis 1.9.5p1 enthalten demnach die Sicherheitslücke.

danke fürs lesen
 

How can I test if I have vulnerable version?​


To test if a system is vulnerable or not, login to the system as a non-root user.


Run command “sudoedit -s /”


If the system is vulnerable, it will respond with an error that starts with “sudoedit:”


If the system is patched, it will respond with an error that starts with “usage:”


┌[bluescreen@gentoo]-(~)-
└> sudoedit -s /
usage: sudoedit [-AknS] [-C num] [-D directory] [-g group] [-h host] [-p
prompt] [-R directory] [-T timeout] [-u user] file ...
┌[bluescreen@gentoo]-(~)-
└>
 
möchte hier jemand etwas über die sudo Sicherheitslücke berichten , wie seid Ihr damit umgegangen?

Code:
ansible-playbook -i inventory/site.yml --limit=hosts-bastille playbooks/sudo-notfall-upgrade.yml

Das Playbook führt im Prinzip nur zwei Kommandos aus:

Code:
bastille pkg ALL update
bastille pkg ALL upgrade sudo

Die Pakete kommen aus meinem eigenem Repo, was ich mit Poudriere baue. Ich hatte nur security/sudo aktualisiert, das Repo einmal neu durchgebaut und dann den Kram ausgerollt. Wobei die Lücke für uns nicht wirklich kritisch war, da die Sicherheit in erster Linie an der SSH-CA hängt und sudo eher eine Art zweiter Barriere ist.
 
und automatische Tests hat

Sind wir mal ehrlich. Das ist die Theorie. In der Praxis geht das Drama doch schon damit los, dass die wenigsten Projekte und kommerziellen Softwareanbieter nur den Security Fix veröffentlichen. Es ist meist eine maximal oberflächlich dokumentierte Suppe aus diversen Security- und Bug Fixes. Womit gar nicht mehr nachvollziehbar ist, was sich genau geändert hat. Nutzt man eine der sogenannten stabilen Distros, mag es besser sein. Aber man muss dafür dann darauf vertrauen, dass der Maintainer des jeweiligen Pakets den Fix zeitnah und vor allem korrekt merged.

Dann lässt man also seine Testsuite laufen, sofern man eine hat. Aber ich habe noch nie eine Testsuite gesehen, die vollständig ist. Und man kann fast drauf wetten, dass nicht der normale, abgedeckte Fall kaputt ist. Sondern irgendwas, was so subtil ist, dass weder die Testsuite es bekommt, noch es sofort auffällt. Das man ein Problem hat, realisiert man oft erst Tage oder sogar Wochen später.
 
Sind wir mal ehrlich. Das ist die Theorie. In der Praxis geht das Drama doch schon damit los, dass die wenigsten Projekte und kommerziellen Softwareanbieter nur den Security Fix veröffentlichen.

Wenn man eigene Umfeld das hergibt, macht man aus der Not eine Tugend. Man hält sein Setup stets aktuell, womit auch ein Security Fix nur ein weiterer kleiner Change wird. Ansonsten kommt leicht in die Situation, sehr kurzfristig große Versionssprünge machen zu müssen.

Von Vorteil ist natürlich, wenn man sein Setup weitestgehend automatisiert, virtualisiert und containerisiert hat.

Es ist meist eine maximal oberflächlich dokumentierte Suppe aus diversen Security- und Bug Fixes. Womit gar nicht mehr nachvollziehbar ist, was sich genau geändert hat. Nutzt man eine der sogenannten stabilen Distros, mag es besser sein. Aber man muss dafür dann darauf vertrauen, dass der Maintainer des jeweiligen Pakets den Fix zeitnah und vor allem korrekt merged.

Deswegen bin ich kein Freund von Distros mit Uralt-Versionen, wenn es nicht unbedingt sein muss.

Dann lässt man also seine Testsuite laufen, sofern man eine hat. Aber ich habe noch nie eine Testsuite gesehen, die vollständig ist.

Die wird uns in diesem Leben auch nicht mehr begegnen. :)

Und man kann fast drauf wetten, dass nicht der normale, abgedeckte Fall kaputt ist. Sondern irgendwas, was so subtil ist, dass weder die Testsuite es bekommt, noch es sofort auffällt. Das man ein Problem hat, realisiert man oft erst Tage oder sogar Wochen später.

Tests vor dem Deployment sind das eine; Monitoring in all seinen Facetten in Produktion das andere. Es hängt halt vom jeweiligen Anwendungsfall ab, wieviel Aufwand man treiben kann, will und sollte - und wie groß im Zweifelsfalle die Auswirkungen sind, wenn einem was durch die Lappen geht.
 
Zurück
Oben