So schließen wir Schwachstellen in Astra Linux Special Edition

Es gibt keine Betriebssysteme ohne Schwachstellen - die einzige Frage ist, wie effektiv die Entwickler sie identifizieren und schließen. Unser Astra Linux Special Edition-Betriebssystem ist keine Ausnahme: Wir überprüfen und testen den Code ständig auf Fehler, Logikverletzungen und andere Fehler und beheben diese schnell. Andernfalls hätte die FSTEC von Russland Astra Linux kaum für die Verarbeitung von Daten zertifiziert, die Staatsgeheimnisse darstellen. Wir werden jedoch in einem anderen Beitrag ausführlicher auf die Zertifizierung eingehen. In diesem Artikel werden wir darüber sprechen, wie Astra Linux-Schwachstellen organisiert sind und wie Bedrohungen der Informationssicherheit mit der inländischen Datenbank interagieren.


Foto: Leonhard Foeger / Reuters

Der erste Ansatz, architektonisch

Um die Sicherheit des Betriebssystems zu verbessern, verwenden wir zwei Ansätze. Das erste, architektonische , ist, dass wir in der Entwurfsphase verschiedene Informationsschutz-Tools entwickeln und implementieren. Diese Werkzeuge bilden einen Komplex von Schutzausrüstung (KSZ) , die Sicherheitsfunktionen implementiert. Mit Hilfe von KSZ versuchen wir sicherzustellen, dass das System das Risiko potenzieller Bedrohungen standardmäßig bereits minimiert.


Architektur der Astra LInux Special Edition Security Suite

Ein Schlüsselelement der KSZ ist der Anrufmonitor , der den unbefugten Zugriff und die Änderung geschützter Komponenten des Systems verhindern soll. Der Monitor bietet eine diskretionäre, rollenbasierte und obligatorische Zugriffskontrolle sowie eine obligatorische Integritätsüberwachung.

Was ist eine obligatorische Integritätsüberwachung ? Lassen Sie uns anhand eines Beispiels veranschaulichen. Eine Schlüsselkomponente des Betriebssystems ist der Kernel. Dementsprechend sind wir verpflichtet, dafür die sicherste Laufzeit im Betriebssystem selbst bereitzustellen, um die Anzahl der möglichen Methoden zum Angriff auf den Kernel zu verringern.

Zu diesem Zweck implementieren wir eine obligatorische Integritätsüberwachung im Betriebssystem, aufgrund derer wir das Betriebssystem nach verschiedenen Subsystemen segmentieren, sodass das Unterbrechen eines Subsystems die Leistung anderer nicht beeinträchtigt. Wenn ein nicht privilegierter Benutzer des Betriebssystems (Integritätsstufe 0) oder eines Netzwerksubsystems (Integritätsstufe 1), eines Virtualisierungssystems (Integritätsstufe 2), einer grafischen Oberfläche (Integritätsstufe 8) oder einer anderen Komponente gehackt wird, bedeutet dies nicht, dass die gesamte KSZ (Integritätsstufe) diskreditiert wird. 63).

Es ist zu beachten, dass diese Ebenen nicht hierarchisch sind, dh sie befinden sich nicht übereinander und sind hinsichtlich der Möglichkeit von Schreibrechten vollständig voneinander isoliert. Der Zugriffsmonitor bestimmt das Zubehör eines Objekts für die eine oder andere Integritätsstufe durch die Bitmaske.



Damit Integritätsstufen nicht als hierarchisch wahrgenommen werden - das heißt zum Beispiel "Stufe 8 hat mehr Rechte als Stufe 2", was falsch ist -, erhält jede Stufe ihren Namen. So wird beispielsweise die achte Integritätsstufe als "Grafikserver" bezeichnet, die maximal mögliche Integritätsstufe des Administrators im System ist "Hoch" und die Integritätsstufe Null (Benutzer) ist "Niedrig".

Der Anrufmonitor, der in unserem vorherigen Artikel beschrieben wurde , steuert und eliminiert die Möglichkeit der gegenseitigen Beeinflussung von Prozessen mit Bezeichnungen unterschiedlicher Integritätsstufen.

Somit erhält das Betriebssystem eine Reihe von Regeln zum Isolieren von Systemprozessen voneinander und versteht nun, welche Prozesse, selbst die von einem Benutzer mit hohen Berechtigungen gestarteten, nicht das Recht haben, in andere Prozesse oder Dateien zu schreiben.

Wenn ein Angreifer infolge der Ausnutzung einer Sicherheitsanfälligkeit (einschließlich Zero Day) die Kontrolle über einen Prozess im System erlangt und seine Berechtigung für einen privilegierten Benutzer (z. B. Root) erhöht, bleibt sein Integritätszeichen gleich und wird dementsprechend nicht empfangen die Fähigkeit, Systemprozesse zu beeinflussen, Einstellungen zu ändern oder Ihre Präsenz im System zu verbergen.


Funktionsprinzip isolierter Integritätsstufen

Somit wird nicht das gesamte Betriebssystem zu einem wichtigen Ziel für einen Angreifer, sondern nur der gehärtete Kernel und der kompakteste Zugriffsmonitor, wodurch die Angriffsfläche bereits erheblich reduziert wird.

Zusätzlich zur obligatorischen gibt es auch eine dynamische und regulatorische Integritätskontrolle. Sie werden verwendet, um den Start und die Verwendung von nicht vertrauenswürdiger Software oder Software von Drittanbietern sowie regelmäßige Überprüfungen der Systemintegrität auszuschließen.

Die dynamische Steuerung berechnet und überprüft die elektronische digitale Signatur ausführbarer Dateien zum Zeitpunkt ihres Starts. Wenn kein EDS vorhanden ist oder wenn es falsch ist, wird der Start von Programmen verweigert. In gewissem Maße handelt es sich hierbei um eine Implementierung des Konzepts der Whitelists, jedoch unter Verwendung einer Hierarchie von Schlüsseln, die an Softwareentwickler ausgegeben werden.


Arbeiten Sie mit dynamischer Integritätskontrolle

Die Routinekontrolle überprüft die Integrität und Unveränderlichkeit von Schlüsseldateien für ein System, indem ihre Prüfsummen mit Referenzwerten verglichen werden. Es können entweder Konfigurationsdateien oder andere sein.

Daher verwendet das Betriebssystem einen mehrschichtigen Schutz vor Schwachstellen in Anwendungen und deren Ersetzung, wodurch Schäden durch Sicherheitsbedrohungen, einschließlich solcher, die Zero-Day-Schwachstellen verwenden, minimiert werden.

Der zweite Prozessansatz

Neben der Architektur verwenden wir gleichzeitig den Prozessansatz : Wir identifizieren und sammeln ständig Informationen über Schwachstellen, verarbeiten diese Informationen und übertragen die Ergebnisse an die Schwachstellendatenbank von FSTEC Russia. Daher bereiten wir geplante und betriebsbereite Betriebssystemupdates vor und veröffentlichen sie. Wir suchen nach Schwachstellen sowohl in Open Source als auch unabhängig voneinander - insbesondere in den Teilen der Software, die wir vollständig selbst entwickeln. Wir erhalten viele Informationen von Partnern, die ähnliche Forschungsarbeiten durchführen - Testen und Studieren der Sicherheit von Betriebssystemen.


Vulnerability Management

Sicherheitsstudien werden hauptsächlich in Bezug auf die Komponenten durchgeführt, die Teil der Astra Linux Special Edition (Smolensk) sind. Gleichzeitig werden Schwachstellen für Astra Linux Common Edition sowohl im Rahmen von Sicherheitsupdates als auch im Rahmen eines geplanten Updates von Systemkomponenten geschlossen.

Sobald wir Informationen über die Sicherheitsanfälligkeit erhalten, prüfen wir, wie relevant diese für unsere Benutzer ist. Wenn die Sicherheitsanfälligkeit nicht kritisch ist, beschreiben wir sie in der nächsten Ausgabe des Security Bulletins auf der offiziellen Website. Benachrichtigungen zur Ausgabe von Stimmzetteln werden dem Benutzer per E-Mail gesendet, deren Adresse in der Lizenzvereinbarung unbedingt angegeben ist. Für kritische Sicherheitslücken werden über mehrere Tage hinweg Richtlinien herausgegeben : Wie können Sie diese selbst beheben, ohne auf ein kumulatives Sicherheitsupdate warten zu müssen? In der Liste der Sicherheitsbulletins sind sie mit den Buchstaben MD (Methodical Direction) gekennzeichnet.

Eine Sicherheitslücke ist hier ein gutes Beispiel, Informationen darüber wurden hier auf Habré veröffentlicht. Übrigens hat der Autor dieses Artikels uns nicht im Voraus kontaktiert und nicht vorläufig mitgeteilt, dass er diese Sicherheitsanfälligkeit erkannt hat und Material vorbereitet. Zur Veranschaulichung haben wir uns entschlossen, den Zeitpunkt der Arbeit an der Sicherheitsanfälligkeit ab dem Zeitpunkt anzugeben, an dem der Text in der Ressource veröffentlicht wurde.

Nachts, am 9. Juli 2019, um 4 Uhr morgens, wurde der Artikel selbst veröffentlicht, der besagt, dass Sie beim Bearbeiten der Bildschirmgröße der virtuellen Maschine die Fenster unter der Bildschirmsperre sehen können.

Es ist anzumerken, dass Sie zur Ausnutzung der auf Video gezeigten Sicherheitsanfälligkeit eine Reihe zusätzlicher Schritte ausführen müssen: Sie müssen zuerst zusätzliche Pakete auf der virtuellen Astra Linux-Maschine und dann auf der Gastmaschine installieren, die für die sofortige Änderung der Auflösung der virtuellen Maschine verantwortlich sind, jedoch nicht sind Teil eines zertifizierten Betriebssystems.

Am 10. Juli 2019 wurden Informationen zu Sicherheitslücken in der FSTEC BDU veröffentlicht. Der Schweregrad der Sicherheitsanfälligkeit wurde als mittel definiert (die Basisbewertung für die CVSS 2.0-Metrik betrug 4,9, für die CVSS 3.0-Metrik - 4).

Am 12. Juli haben wir das Security Bulletin Nr. 20190712SE16MD für Astra Linux Special Edition Version 1.6 und das Security Bulletin Nr. 20190712SE15MD für Astra Linux Special Edition Version 1.5 veröffentlicht. Ein ähnliches Sicherheitsupdate wurde von der Astra Linux Common Edition erhalten.

Somit sind weniger als 4 Tage seit der Veröffentlichung von Informationen über die mittlere Sicherheitsanfälligkeit für die Veröffentlichung des Patches für alle Versionen von Astra Linux (wo Virtualisierung möglich ist) vergangen.


Live-Update-Schema für Astra Linux

Mindestens einmal im Quartal veröffentlichen wir Sicherheitsupdates - Betriebsupdates , die bisher unbekannte Schwachstellen beseitigen, einschließlich Anwendungssoftware, Bibliotheken und Betriebssystemfunktionen, die keine Sicherheitsanforderungen implementieren. Wenn Sicherheitsbedrohungen, die mithilfe der Sicherheitsanfälligkeit implementiert wurden, nicht durch Ausgleichsmaßnahmen ausgeschlossen werden können, wird derzeit an der Fertigstellung des Betriebssystems gearbeitet. Nach Abschluss der Entwicklung und des Testens des Sicherheitsupdates veröffentlicht die Website auch den Newsletter und das Update selbst. In den ersten sechs Monaten des Jahres 2019 wurden zwei kumulative Updates für die Astra Linux Special Edition Version 1.6 veröffentlicht, die Hunderte verschiedener Sicherheitslücken abdecken. Jetzt wird der dritte für die Veröffentlichung vorbereitet.

Schließlich interagieren wir aktiv mit der Entwickler-Community:

• Wir informieren in Projekt-Bugtrackern über selbst erkannte Fehler;
  
• Wir übertragen vorgefertigte Korrekturen von Mängeln, die von uns geschlossen wurden, auf die Projekte.
  
• Wir appellieren an die Community, bei der Beseitigung von Mängeln behilflich zu sein. Wenn Sie die Logik des Programms kennen, können Sie eine um eine Größenordnung schnellere Korrektur erzielen als beim alleinigen Reverse Engineering.
  
• Wir verwenden alle von der Community herausgegebenen Fixes und nehmen sie in unsere Updates auf. Wir verstehen, dass dadurch die Qualität des Produkts verbessert wird. Gleichzeitig wenden wir die im vorherigen Artikel beschriebenen Methoden zur Kontrolle und Vertrauensbildung an.
  

Offenheit ist wichtig

Da unser Betriebssystem von der FSTEC Russlands zertifiziert ist, fügen wir zunächst Informationen zu den gefundenen Sicherheitslücken in die FSTEC Information Security Threat Data Bank (DBU) zur offiziellen Veröffentlichung ein: Wenn Sie zur DBU gehen , finden Sie Informationen zu mehr als 350 behobenen Sicherheitslücken in verschiedenen Versionen von Astra Linux sowie detaillierte Informationen dazu.



So sorgen wir für Offenheit in der Arbeit. Dank dessen können Benutzer - einschließlich des Regulators - bis zu einem gewissen Grad sicher sein, dass die Sicherheit tatsächlich unter Kontrolle ist. Es reicht nicht aus, ein Update zu erhalten. Sie müssen wissen, welche spezifischen Sicherheitslücken es geschlossen hat.

Bisher ist unser Architektur- und Prozessansatz zur Aufrechterhaltung der Betriebssystemsicherheit völlig gerechtfertigt - wir halten erfolgreich ein hohes Maß an Sicherheit für Informationssysteme mit dem Betriebssystem Astra Linux Special Edition aufrecht. Der offene Zugriff auf Informationen zu Sicherheitslücken über das FSTEC-Kontrollfeld erhöht das Vertrauen in unser Produkt.

Gerne beantworten wir in den Kommentaren Fragen zur Sicherheit unseres Systems. Wenn Sie etwas Neues über das System erfahren möchten, hinterlassen Sie Ihre Wünsche - wir werden sie bei der weiteren Arbeit mit dem Blog berücksichtigen.