Testing wie "(un)sicher" wirklich?

[debianx]

Hallo eine kurze Basisfrage zur Sicherheit insbesondere was Netzwerk und Verschlüsselung angeht.

Wenn man ein System mit testing(Bullseye) nutzt, mit welchen konkreten Sicherheitslücken bzw Risiken muss man rechnen?

Auf der offiziellen Debian Seite wird recht deutlich gewarnt, wobei ich in anderen Quellen lese, dass man testing eigentlich auch relativ bedenkenfrei nutzen kann.

Wenn man ein Paketfilter einsetzt mit iptables, muss man dann davon ausgehen, dass eine damit eingestellte "Firewall" weniger sicher ist als wenn ich iptables mit stable(Buster) nutze?
Das gleiche würde mich auch im Bezug auf System-Verschlüsselung mit dm-crypt interessieren.

Also kurz gefragt: Ist die Funktion von iptables und dm-crypt auf testing unsicherer als auf stable oder ist das gleich sicher?

[TRex]

Die (Un)Sicherheit von testing kommt daher, dass Sicherheitslücken (und sonstige Probleme) erstmal auf sid gefixt werden, und dann den normalen Prozess zu testing und via shortcut über debian-security zu stable nehmen. Ersteres dauert ein paar Tage, und eine Versorgung via debian-security ist nicht vorgesehen.

Aber zeig mir erstmal ne CVE zu iptables und/oder dm-crypt, und dann zeig ich dir im debian-tracker, wie lange es gedauert hat, bis es in testing war

[debianx]

Die (Un)Sicherheit von testing kommt daher, dass Sicherheitslücken (und sonstige Probleme) erstmal auf sid gefixt werden, und dann den normalen Prozess zu testing und via shortcut über debian-security zu stable nehmen. Ersteres dauert ein paar Tage, und eine Versorgung via debian-security ist nicht vorgesehen.

Mit diesen Vorgängen kenne ich mich leider gar nicht gut aus aber es handelt sich zumindest um unterschiedliche Versionen wenn ich es richtig sehe, die Frage wäre ob die neuere Version eben potentiell "unsicherer" ist. dm-crypt konnte ich nicht finden aber entspricht evt cryptsetup...

buster:
iptables (1.8.2-4)
cryptsetup (2:2.1.0-5+deb10u2)

bullseye:
iptables (1.8.4-3)
cryptsetup (2:2.3.1-1)

Aber zeig mir erstmal ne CVE zu iptables und/oder dm-crypt, und dann zeig ich dir im debian-tracker, wie lange es gedauert hat, bis es in testing war

Bedeutet was genau einfach gesagt?
Das Lücken bei iptables und/oder dm-crypt sehr unwahrscheinlich sind, auch bei testing?

Gruß

[TRex]

Mit diesen Vorgängen kenne ich mich leider gar nicht gut aus

Da kommst du nun aber nicht umher, dich damit wenigstens grundlegend zu beschäftigen. Die Detsils sind nicht wichtig, aber: in sid landen die neuen Programmversionen und Patches. Wenn die dort lange genug abgehangen wurden (das heißt, die Verwender von sid haben keine kritischen bugs gefunden und ein Mindestmaß an Zeit ist vergangen), kommen sie zu testing. Und alle Jahre (1,5?) wieder wird die Maschinerie angehalten, die restlichen Bugs in testing gefixt und stable released. Securitypatches kriegen wie schon erklärt Sonderbehandlung durch das debian-security Team und kommen schnellstmöglichst direkt von sid nach stable.

ob die neuere Version eben potentiell "unsicherer" ist

Das ist zu vereinfacht formuliert. Neue Programmversionen können *immer* neue Bugs enthalten. Machst ein Loch zu, ein neues Feature dazu, und hast plötzlich zwei Bugs mehr im Code. Darum werden Securitypatches in debian einzeln angewendet, und nicht einfach die ganze Version eines Programms in stable aktualisiert. Daher kommen die Bezeichnungen mit +deb10u2 her, da wurden zwei Patches auf der 2.1.0.5 angewandt (die mit debian 10 ursprünglich veröffentlicht wurde).
2:2.1.0-5+deb10u2 ist demnach sicherer als 2:2.1.0-5, und man kann keine Aussage zu 2:2.3.1-1 treffen (du kannst im Changelog nachlesen, ob die beiden Patches da bereits durch Upstream, also die eigentlichen Entwickler, bereits integriert wurden).

Das Changelog zu cryptsetup: https://metadata.ftp-master.debian.org/ ... _changelog
Das einzige dort erwähnte CVE: https://security-tracker.debian.org/tra ... -2016-4484
Und auf Seite 3 des Trackers, die Zeiten, wann es in unstable und testing aufgeschlagen ist: https://tracker.debian.org/pkg/cryptsetup/news/?page=3

[2016-11-14] cryptsetup 2:1.7.3-2 MIGRATED to testing (Debian testing watch)
[2016-11-07] Accepted cryptsetup 2:1.7.3-2 (source amd64) into unstable (Jonas Meurer)

Weiterhin relevant: http://hmarco.org/bugs/CVE-2016-4484/CV ... shell.html
Dort steht nämlich, dass man am 11.11. das Teil auf ner Konferenz besprochen hat. War in dem Fall nicht so wild, und man geht mit kritischen Bugs sicher weniger früh raus, wenn der Patch nicht verteilt ist, aber... naja. Soll jeder selbst nachdenken und in Panik ausbrechen. Hat auch ne recht niedrige Severity.

Schauen wir uns doch mal den Grund für die u2 an (steht im changelog). Der kam neben anderem durch bug 935702. Weiter unten findet man die gepatchten Uploads für den Bug.
2:2.1.0-5+deb10u2 für buster (stable) und
2:2.2.0-3 für sid.

Der fix kam an:

[2019-08-31] Accepted cryptsetup 2:2.1.0-5+deb10u2 (source) into proposed-updates->stable-new, proposed-updates (Guilhem Moulin)
[2019-08-31] cryptsetup 2:2.2.0-3 MIGRATED to testing (Debian testing watch)
[2019-08-26] Accepted cryptsetup 2:2.2.0-3 (source) into unstable (Guilhem Moulin)

Vier Tage, bis der Patch sowohl in stable als auch testing war.

Und nun der wichtigste Faktor: du. Hast du dein System an jedem Tag aktualisiert und ggf. rebootet?

Zum Abschluss:

Das Lücken bei iptables und/oder dm-crypt sehr unwahrscheinlich sind, auch bei testing?

Je verbreiteter (und dadurch getesteter) und kleiner die Software, desto sicherer ist sie tendenziell. iptables und dmcrypt sind klein, abgehangen und durch das, was sie tun, besonders interessant für "Sicherheitsforscher". Wenn du dir wegen irgendwas Sorgen machen willst, schau dir dein Wordpress-blog an und die Plugins, die du da installiert hast. Einmal falsch angucken, und die zusammengewürfelte Bananenbloatware gibt dem ostasiatischen Nachwuchshacker ne root-shell.
Mit testing hat das nicht viel zu tun. Sobald du übrigens in ubuntu ne ppa einbindest oder bei debian eine Fremdquelle in der sources.list, hast du mindestens das gleiche Risiko wie bei testing/unstable.

[OrangeJuice]

Dann bleibt noch das mögliche Risiko, dass durch das Zurückportieren entstehen könnte(Teardown of a Failed Linux LTS Spectre Fix).

Wie groß und schlimm das Risiko wirklich ist und wie oft so etwas passiert, weiß ich nicht. Wäre wahrscheinlich nicht so gut gewesen, wenn das über Jahre so drin geblieben wäre. Hat alles seine Vor- und Nachteile.

[debianx]

@TRex Danke für die gute Einführung in das Thema, im Großen und Ganzen klingt das doch extrem solide wie das abläuft. Wenn dabei dann die genannte Software noch die Eigenschaften eines kleinen und gut abgehangenen Parmaschinken besitzt, dann muss man sich vermutlich wirklich sehr wenig Sorgen machen, also so interpretieren ich das jetzt mal.
Eine neuere Version einer Software bedeutet vermutlich auch nur eine minimale Änderung vom Bestandscode, es wird wohl in den meisten Fällen nicht die ganze Software neu gestaltet sondern immer nur ein kleiner Teil verändert oder hinzugefügt damit bleibt der prozentuale potentielle Bugcode vermutlich auch relativ klein.