byebye, SLES 9

Heute kam wenig überraschend eine Mail von Novell, dass der SLES 9 Support nun nach 7 Jahren zu Ende ist – außer man ist LTS Kunde – was wohl ziemlich teuer wird und nur für Großunternehmen Sinn macht. SLES9 ist so dermaßen angegraut, beim Blick auf die Paketversionen wird man schon leicht Nostalgisch… ;D

 

Interessant sind die Statistiken:

Gesamte Updates: 1565
Security: 767
Empfohlen: 718
Optional: 72
YaST: 8

Das CVE-Tracking war im ersten Jahr nicht vollständig, daher sind die Nummer eigentlich etwas höher.

Insgesamte CVE-Einträge: 1447

Top CVE-Kanidaten:

127 IBM Java 5
125 IBM Java 1.4.2
84 kernel
66 SUN Java 1.4.2
76 clamav
68 ethereal
58 mozilla
44 cups
32 mysql
31 libpng
28 freetype2
24 ruby
21 XFree86
20 libexif
18 mailman
18 horde
16 quagga
17 tomcat
16 apache2
15 openssh
15 gd
14 python
13 yast2-packagemanager-devel
13 km_nss
12 openssl
12 samba
11 tk
10 pcre

Interessant, dass der Kernel sogar schlimmer als Mozilla war…ich dachte das wäre unmöglich… :/ Clamav mit 76 Löchern finde ich aber auch eine ziemliche Katastrophe, zumal das ja auch oftmals auf Mailgateways läuft…

This entry was posted in Linux, Rechenzentrum, Security and tagged , , , , . Bookmark the permalink.

2 Responses to byebye, SLES 9

  1. Tim says:

    Wir haben noch dreimal SLES 9 im Einsatz, weil die Applikationsjungs einfach ihren ***** nicht hochbekommen. Bin gespannt, wann da mal wirklich was richtig schön kaputt geht.
    Aber eigentlich wollte ich was anderes sagen: Warum ist Software “schlimm” wenn viele Löcher gefixt wurden? Ich finde das ist eher ein gutes Zeichen. Es zeigt, dass es ein aktives Security Team und aufmerksame Leute gibt. Wer weiss wieviele nicht veröffentliche Löcher es in den anderen Softwares gibt, die die bösen Cracker für viele Dollars sich gegenseitig verkaufen…

  2. admin says:

    Manche Software wird einfach nicht nach üblichen Sicherheitsstandards programmiert und hat daher immer wieder ähnliche Probleme. Viele Sicherheitsprobleme in Software sind nie ein gutes Zeichen. Postgres taucht z.B. nicht in der Liste auf – wird es weniger auditiert? Ich denke nicht.

    Leute, die Code Audits von Serversoftware machen, verkaufen die Sicherheitslöcher m.A. nicht an Cracker, sondern eher an Securityprogramme wie Tippingpoint. Dort kann man sicher sein, dass man sein Geld bekommt und fühlt sich auch vielleicht besser. Für die bösen Cracker sind clientseitige Löcher (Browser!) wesentlich lukrativer.

Leave a Reply

Your email address will not be published. Required fields are marked *