Golem: Angriffe auf den FreeBSD-Update-Prozess

Dazu gab es Ende Juli, als die Sache publik wurde, ein Diskussion auf freebsd-security@. Das FreeBSD Security Team hatte zur gleichen Zeit bspatch per Security Advisory gepatcht. Meinem vielleicht zu eingeschränkten Verständnis nach setzt dieser Angriff voraus, dass der Angreifer den Update-Server oder den Datenkanal zwischen Server und Client kontrolliert. Wenn das stimmt, wäre der Angriffsvektor eher theoretisch, da die meisten Nutzer den offiziellen Server über HTTPS nutzen und bisher nicht öffentlich bekannt geworden ist, dass diese kompromitiert wurde.

Und ganz ehrlich: Ich traue dem FreeBSD Security Team weitaus mehr, als Golem.de. Wenn es da ein Problem gibt, wird es zur gegebenen Zeit ein Statement geben. Wobei sich das Security Team traditionell nur äußert, wenn es auch wirklich etwas zu berichten gibt.
 
Ich hab das ebenfalls so verstanden wie @Yamagi. Der Angriff setzt eine MITM-Attacke vorraus. Bei eine Kompromittierung des Update-Server ist m.M.n. eh alles zu spät.

*Typo fix
 
Wenn das stimmt, wäre der Angriffsvektor eher theoretisch, da die meisten Nutzer den offiziellen Server über HTTPS nutzen
Ich habe das gerade mal per tcpdump bei mir gecheckt und da geht alles über http. Noch dazu ist https für surfen schon so-la-la, aber sich für seine system-updates darauf zu verlassen?
Man muss ja nicht paranoid sein, aber nachdem wir jetzt wissen wieviele Organisationen in der Lage sind MITM auszuführen finde ich die mangelnde/geringe Reaktion des FreeBSD-Projekts schon ein wenig suboptimal...
 
Ich habe das gerade mal per tcpdump bei mir gecheckt und da geht alles über http.
Stimmt. Ich war fest davon ausgegangen, dass SSL genutzt wird und hatte daher auch gar nicht weiter geschaut. Aber 'phttpget' scheint tatsächlich nur klassisches, unverschlüsseltes HTTP zu können. :(
 
Dieses Thema wurde auch im jüngsten BSD Now Podcast ausgebreitet. Die beiden sind sicherlich keine Security Experts... aber vielleicht habe ich deshalb ein bisschen besser verstanden, worum es geht.

Das Problem mit HTTPS ist demnach, dass FreeBSD nicht mit einem Set von vertrauenswürdigen Zertifikaten kommt, die es überprüfen könnte (sowas wie security/ca_root_nss ist ja nicht in Base). Und die langen Support-Zeiten machen es auch nicht gerade wahrscheinlich, dass solche Zertifikate aktuell blieben. Da muss man aufpassen, dass man nicht einen Mechanismus wie freebsd-update lahm legt, weil ein einmal hinterlegtes Zertifikat ein paar Jahre später nicht mehr gültig ist.
 
Was in dem BSD Now Podcast gesagt wird ist, dass man für Angriffe Vollzugriff (root) auf's System brauchst. Das heißt der Nutzen ist wenn dann ser theoretisch. Wenn jemand root-Zugriff hat dann ist nicht mehr wirklich viel da was der Angreifer noch bekommen kann insofern bringt einem der Angriff nicht viel.
 
golem.de schrieb:
FreeBSD selbst nutzt zudem noch eine ältere Version von Libarchive (3.1.2). In den vergangenen beiden Updates, 3.2.0 und 3.2.1, wurden eine ganze Reihe von Memory-Corruption-Lücken behoben, einige davon hat der Autor dieses Artikels gemeldet.

Und ich habe gleich nachgeguckt, hier auf FreeBSD 10.3-STABLE amd64:
Code:
bsdtar --version

bsdtar 3.2.1 - libarchive 3.2.1 zlib/1.2.8 liblzma/5.2.2 bz2lib/1.0.6
Die Aktualisierung auf die libarchive Version 3.2.1 war vor 5 Wochen:
http://svnweb.freebsd.org/base/stable/10/contrib/libarchive/libarchive/?sortby=date#dirlist

Aktuell halten über die neuen Binary Update Werkzeuge ist ja zudem auch nicht die einzige Möglichkeit, FreeBSD bietet ja auch die Freiheit immer noch die traditionelle Quellcode synchronisieren und selbst bauen Methoden zu verwenden. Bei mir hier ist das Gewohnheit.
 
@KobRheTilla Da ging es auch darum dass der MITM lokal passieren muss. Also Files vor-platzieren. Das heißt selbst wenn man es als root ausführt, regelmäßig oder so ist das scheinbar kein möglicher Attack-Vektor wenn man nict zuerst (als root) ein paar Files platziert hat.
 
Wo ich dies hier gerade sehe:
https://github.com/libarchive/libarchive/issues/513
.. was auf der The Fuzzing Project Seite aufgeführt wurde:
https://blog.fuzzing-project.org/47-Many-invalid-memory-access-issues-in-libarchive.html

Da ist inzwischen auch
https://sourceforge.net/p/p7zip/discussion/383043/thread/9d0fb86b/
p7zip 16.02 veröffentlicht worden.
Auf Kompressionswerkzeuge und Archiventpacker muss man wohl immer wieder mal ein waches Auge haben:
https://www.bsdforen.de/threads/p7zip-cve-2016-2334-cve-2016-2335.32629/
 
The function fetch_snapshot_verify() contains the following hash check:

Code:
if [ "`gunzip -c snap/${F} | ${SHA256} -q`" != ${F} ]; the

The problem is that ${F} expands to a file hash without any .gz suffix. As documented in the gunzip(1) manual page, gunzip(1) will first try opening the file snap/${F}. Failing that, it will automatically append a suffix and try opening the file snap/${F}.gz.
An attacker can supply both snap/${F} and snap/{F}.gz, where the first file is clean and passes the hash check and the second file is malicious. Because the portsnap(8) script explicitly appends a .gz suffix for every other use of gunzip(1), the attacker's malicious file will be the one chosen for extraction.

Ich weiß schon, warum ich von diesen ganzen angeflanschten Update-Mechanismen die Finger lasse. Ich weiß nicht, was bei den FreeBSD-Leuten schiefläuft, aber das ist einfach nur armselig und eines BSDs unwürdig.
 
Das offizielle Statement:
Code:
Dear FreeBSD Community:

The FreeBSD Core team and FreeBSD Security team would like to update the
community on the reports of security vulnerabilities in freebsd-update,
portsnap, libarchive, and bspatch.

We understand the severity of this issue, and are actively working to resolve
the issues and improve the security of FreeBSD.

A recent post[1] to the freebsd-security@ list raised a number of questions[2]
and we would like to address those.

  1. Since there are known vulnerabilities in freebsd-update and
  portsnap, why has there been no notification to the community
  from secteam@?

  As a general rule, the FreeBSD Security Officer does not announce
  vulnerabilities for which there is no released patch. We are
  reviewing this policy for cases where a proof-of-concept or working
  exploit is already public.

  2. Why was there no mention of the fact that running freebsd-update
  to install the fix for the bspatch advisory [SA-16:25] may actually
  expose users to the vulnerability?

  To be exposed, a user would need to be under an active
  Man-In-The-Middle attack when fetching patches. The Security
  Advisory did not contain information on the theoretical implications
  of the vulnerability. A more explicit paragraph in the 'Impact'
  statement may have been warranted. As always, instructions on how to
  compile the patched bspatch manually rather than using
  freebsd-update were provided as part of the advisory.

  3. The patch included in SA-16:25 is incomplete, and may still
  permit heap corruption. The patch included in the document dump
  is more complete. Why only a partial fix?

  After discussion with the author of bspatch (Colin Percival, a
  former FreeBSD Security Officer himself), The FreeBSD Security Team
  found that the proposed patch added restrictions that may break
  (legitimate) functionality in bspatch, possibly preventing some
  valid patch files from being accepted. While a full fix is being
  developed, the shorter patch which resolves the main vulnerability
  was immediately released. This resolves the most critical issue in
  the report. This smaller patch is safe, in that it does not risk
  breaking bspatch while still resolving the attack vector of the
  provided exploit code. The larger patch is still under development
  and will be released once all of the issues have been
  addressed. Automated fuzz testing is underway to search for any
  additional memory corruption bugs.

Great care must be taken when updating the binary upgrade utility, as it
becomes much more difficult to fix after the fact, as the updater is then
broken. There are delicate interactions between the components that must be
thoroughly tested before the patch is released.

As of yet, patches for the libarchive vulnerabilities have not been released
upstream to be pulled into FreeBSD. In the meantime, HardenedBSD has created
patches for some of the libarchive vulnerabilities, the first[3] is being
considered for inclusion in FreeBSD, at least until a complete fix is
committed upstream, however the second[4] is considered too brute-force and
will not be committed as-is. Once the patches are in FreeBSD and updated
binaries are available, a Security Advisory will be issued.

The Security team is working on redesigning freebsd-update and portsnap to do
signature verification on all downloaded files before they are processed by
libarchive/tar, bspatch, or any other utilities. However, this change requires
modifying the metadata format used in the utilities, and care must be taken to
preserve compatibility with the existing clients, so the existing clients can
be used to install the future updates. Users will of course have the option to
build/apply the patches themselves if they do not feel comfortable using
freebsd-update to do so.

The security team is working diligently to resolve the issues and provide
timely, correct fixes for all known issues. Please subscribe to the
freebsd-security-notifications@ mailing-list to receive notifications of any
future Security Advisories.

[1]https://lists.freebsd.org/pipermail/freebsd-security/2016-July/009016.html
[2]https://lists.freebsd.org/pipermail/freebsd-security/2016-July/009019.html
[3]https://github.com/HardenedBSD/hardenedBSD/commit/acc5eaecbe4970cfb96d9549fe7dc8ceb4676557
[4]https://github.com/HardenedBSD/hardenedBSD/commit/6a6ac73ae630927b2dd996df3cd85c8c612c459c
 
@TCM: Wie's aussieht wird sich freebsd-update potentiell bald erübrigen:

Um diese Inhalte anzuzeigen, benötigen wir die Zustimmung zum Setzen von Drittanbieter-Cookies.
Für weitere Informationen siehe die Seite Verwendung von Cookies.
 
Ich verstehe das doch richtig, dass wir hier im Wesentlichen zwei "neue" Angriffsvektoren haben und die ganze Aufregung auf Golem deswegen eher überflüssig war?

  1. Updatedownload von einem kompromittierten Server. Wäre ich halbwegs versierter Angreifer, würde ich aber auch die Signaturen mitfälschen. Somit kein FreeBSD-Problem, sondern ein Problem mit allem, was das Internet nach Updates durchsuchen kann.
  2. Lokaler Symlink-Exploit. Dafür müsste aber erst mal jemand auf meinen Server (als Benutzer) draufkommen – und dann hätte ich wirklich größere Probleme.

Oder?
 
Zurück
Oben