Probleme beim Einspielen des MacBook Air Flash Storage Firmware Update 1.1

Wie unter anderem Heise berichtete, hat das MacBook Air in der 2012er Version unter Umständen ein Problem mit der verbauten SSD. Dies tritt bei den Modellen mit 64er und den 128 GiB SSDs auf. Probleme machen dabei nur SSDs von Toshiba. Von Samsung verbaute Festplatten aus dem gleichen Zeitraum sind nicht betroffen.

FileVault muss für das Update deaktiviert werden

FileVault muss für das Update deaktiviert werden

Apple hat zur Lösung der Probleme das „MacBook Air Flash Storage Firmware Update 1.1“ herausgebracht. Beim Einspielen des entsprechenden Updates kann es allerdings auf manchen Systemen zu Problemen kommen. Diese äußern sich darin, das nach dem augenscheinlich erfolgreichen Einspielen des Updates, dieses ein zweites Mal angeboten wird. Der Verursacher dieses Problems ist dabei FileVault. Dieses muss temporär deaktiviert werden. Nach der Entschlüsselung des Laufswerkes kann das Update eingespielt werden. Nach dem erfolgreichen Update kann FileVault wieder aktiviert werden.

Probleme mit Mupen64 auf der OUYA

Für die Emulation des Nintendo 64, gibt es im OUYA Store die App „Mupen64“. Mit dieser ist es möglich alte Nintendo 64 Spiele zu emulieren. Problematisch wird es nur wenn man mit mehr als einem Spieler spielen möchte.

Ein weiterer Controller wurde aktiviert

Ein weiterer Controller wurde aktiviert

Startet man den Emulator mit zwei angemeldeten OUYA Controllern, so wird trotzdem nur einer im Spiel genutzt werden können. Die Lösung des Problems ist dabei in den Einstellungen zu finden. In diesen muss man jeden zusätzlichen Controller für das emulierte Nintendo 64 freischalten. Allerdings reagiert die entsprechende Option nicht auf irgendwelche Buttondrücke. Stattdessen muss man das eingebaute Touchpad des Controllers benutzt werden um den Schalter per Klick umzustellen. Danach kann man in der Emulation mehrere Controller nutzen.

Probleme mit ejabberd und Pidgin unter Windows

Wenn man einen XMPP Server mittels „ejabberd“ eingerichtet hat und für diesen SRV Einträge in der DNS eingerichtet hat, kann es passieren, das die Windowsversion von Pidgin sich nicht mit diesem Server verbinden kann. Pidgin meldet sich dabei nur mit dem Fehler „Nicht autorisiert“. Der Grund dafür ist ein Bug, welcher sich in die Version 2.10.7 eingeschlichen hat.

Der gemeldete Bug im Ticketsystem

Der gemeldete Bug im Ticketsystem

Mittlerweile ist dieser behoben, so das der Login im nächsten Release (2.10.8) wieder funktioniert. Solange sollte man die Vorgängerversion (2.10.6) nutzen, welche bei SourceForge heruntergeladen werden kann.

Probleme mit dem SSH Zugang per Schlüssel

Möchte man sich auf einem Linux-Server per SSH Schlüssel anmelden, so kopiert man im ersten Schritt seinen Schlüssel auf den entfernten Server:

ssh-copy-id -i ~/.ssh/id_rsa.pub 

Anschließend kann man sich mittels:

ssh 

ohne Passworteingabe auf den Rechner einloggen. Sollte dies nicht der Fall sein, gibt es ein Problem. So kann es passieren das man trotz SSH-Schlüssel ein Passwort eingeben soll. Um die Ursache zu diagnostizieren hilft es „ssh“ im Verbose-Modus zu benutzen:

ssh -v 

Im diesem Modus werden viele Debuginformationen ausgegeben, welche helfen können das Problem einzugrenzen. Das man Passwörter trotz eines SSH Schlüssels eingeben muss, liegt manchmal an falsch konfigurierten Dateirechten im „.ssh“ Ordner auf dem entfernten Rechner. Die einfachste Möglichkeit ist es hier den Ordner komplett zu entfernen, damit er vom System nochmal angelegt wird. Dazu muss der Schlüssel natürlich mittels „ssh-copy-id“ wieder auf dem Rechner angebracht werden. Alternativ ist es auch möglich die Rechte für diesen Ordner neu zu setzen:

chmod 700 /home/seeseekey/.ssh/
chmod 600 /home/seeseekey/.ssh/authorized_keys

Wenn der Verbose-Modus nicht die gewünschten Ergebnisse bringt, so sollte sich die Logdatei /var/log/auth.log“ angeschaut werden. Dort kann man dann z.B. solche Meldungen bewundern:

Sep 21 01:47:35 service sshd[34221]: Authentication refused: bad ownership or modes for directory /home/seeseekey

In diesem Fall lag es nicht nur am „.ssh“ Verzeichnis, sondern auch an dem Homeverzeichnis des Nutzers. Ein:

chmod 700 /home/seeseekey/

wirkt in einem solchen Fall wahre Wunder. Danach sollte auch die Authentifikation per SSH-Schlüssel wieder funktionieren.

Fingerabdruck gefällig?

Apples neuster „Geniestreich“ soll er sein – der Fingerabdruckscanner welcher sich unter dem Homebutton befindet. Sensibel ist es natürlich nicht, so etwas auf dem Gipfel eines Überwachungskandales noch nie gekannten Ausmaßes herauszubringen. Nun muss man Apple natürlich zu Gute halten, das der Einbau des Scanners sicherlich schon sehr lange geplant war und die Veröffentlichung nur zur falschen Zeit kam. Trotzdem vereint dieses System einige sehr unangenehme Eigenschaften welche es unbrauchbar machen.

Auch wenn Apple bei der Keynote versprochen hat, das der gespeicherte Fingerabdruck nur lokal auf dem Gerät gespeichert wird und niemals in die iCloud oder auf Apple Server (von anderen Servern war nicht die Rede) hochgeladen wird, muss das nicht heißen das niemand an diese Abdrücke herankommt. Gemäß der Maxime, wo ein Wille da auch ein Weg, wird es sicherlich eine Möglichkeit geben diese Daten auszulesen.

Die Codeeingabe ist sicherer als der Fingerabdruck

Die Codeeingabe ist sicherer als der Fingerabdruck

Es gibt im Moment zirka 700 Millionen iOS Nutzer. Wenn man davon ausgeht, das in relativ kurzer Zeit 50 Millionen Nutzer über ein iOS Gerät mit Fingerabdruckscanner verfügen, dann haben wir eine wunderschöne Datenbasis. Und große Datensammlungen wecken immer Begehrlichkeiten. Erst recht wenn es sich dabei um so sensitive Informationen wie den eigenen Fingerabdruck handelt.

Das nächste Problem bei einer Anmeldung mittels des Fingerabdruckes ist die Tatsache das sich ein solcher für eine sichere Authentifizierung nicht eignet. Im Gegensatz zu einem Schlüssel oder unserer PIN hinterlassen wir ständig und überall unsere Fingerabdrücke – auf Gläsern, Möbeln und auf dem iPhone selbst. Das entspricht dem Sicherheitsniveau eines Haustürschlüssels unter dem Türvorleger.

Die Wahrscheinlichkeit das jemand anders das iPhone mit seinem eigenen Finger entsperren kann, liegt im übrigen bei 1:50000 – das bedeutet, das einer von 50.000 Menschen auch an ihr iPhone kommt. Bis hierher ist das natürlich eine eher theoretische Bedrohung. Fingerabdrücke lassen sich allerdings relativ einfach kopieren, was drei Tage nach dem Erscheinens des iPhone 5S eindrucksvoll bewiesen wurde. Jan Krissler dachte sich für die Überwindung keine neuen Verfahren aus, sondern nutzte eine bekannte Methode und entsperrte das iPhone mit einem Kunstfinger. Die Lebenderkennung wurde dabei durch das Anhauchens des Kunstfinger überwunden.

Auch im Alltag behält der Scanner einige unangenehme Überraschungen bereit. So wurde das Handy des Abgeordneten Andreas Baum von einem Polizisten ohne dessen Einwilligung durchsucht. In seinem Fall hatte er keine Codesperre im Gerät, allerdings benötigt man kein Einverständnis mehr bei einem Zugang per Fingerabdruck. Während der Code für das eigene Telefon nicht herausgeben werden muss, kann ein Polizist bei einer solchen Durchsuchung, den Nutzer einfach dazu zwingen meinen Finger auf das Gerät zu legen. Mit ein bisschen Gewalt geht da einiges. Wer jetzt der Meinung ist das das nicht rechtens ist – auch die erkennungsdienstliche Behandlung (inklusive Fingerabdrücke) kann unter Zwang vorgenommen werden.

Das Fazit ist vernichtet. Die Fingerabdruckfunkion ist nicht nur untauglich, sondern gefährlich – da sie dem Nutzer einige essentielle Schutzmaßnahmen nimmt. Ein Passwort kann er für sich behalten, einen Fingerabdruck nicht. Ein Fall wird trotzdem nicht eintreten. Wer sich in den Authentifizierungsfinger schneidet, kann über die Notruffunktion immer noch Hilfe rufen, denn diese funktioniert ohne eine Sicherheitsabfrage. Es sollte auch das einzige sein, was bei einem Mobilgerät ohne Authentifikation über einen Sicherheitscode oder ein entsprechendes Muster funktioniert.