Kategorien
Sicherheit

Thunderbird Bug, verzögertes öffnen von PDF’s

Folgendes Szenario:

Gemischte Umgebung mit Windows 7 und Windows 10, Thunderbird in Version 60.6.1 oder 60.9.0, Acrobat Reader in Version 11.0.23. Beim Öffnen von PDF Anhängen gibt es auf manchen PC’s das Problem dass der Anhang erst nach über 10 Sekunden geöffnet wird. Speichert man ihn lokal ab und öffnet ihn von dort ist er sofort offen. Es wird auch sofort beim Klick auf den Anhang die PDF Datei auf der Platte erstellt, die Verzögerung von 10 Sekunden lässt sich nicht wirklich erklären. Sämtliche Reparaturversuche und Programm Neuinstallationen bringen nichts.

Nach längerer Suche habe ich mich mit dem ProzessManager von Sysinternals auf die Suche gemacht und auf einem PC bei dem es problemlos lief einen Trace der Prozesse mit „thunder“ sowie jener mit „acrord“ im Namen gemacht.

Im Trace ist mir dann aufgefallen dass jene Systeme bei denen es nicht funktioniert eine Verbindung wie folgt aufbauen:

08:13:33,3827524″,“thunderbird.exe“,“2692″,“TCP Reconnect“,“X1234.dummy.domain:53950 -> prg03s02-in-f110.1e100.net:https“,“SUCCESS“,“Length: 0, seqnum: 0, connid: 0″

Und jene bei denen es Problemlos funktioniert haben hier eine ganze Abfolge TCPSend, TCPReceive stehen statt der Reconnect Meldungen.

Die Host Adresse 1e100.net hat mich dann auf die richtige Fährte gebracht! Diese gehört zu Google (1 hoch 100 = gogol, davon abgeleitet google…). Etwas Recherche im Internet bringt also die SafeBrowsing Funktion von Firefox/Thunderbird zum Vorschein, die greift auf diese Adressen zu und schickt einen SHA256 Hash zur Prüfung ob der jeweilige Anhang koscher ist oder nicht.

Mal davon abgesehen dass es wenn’s um die Privatsphäre geht nicht unbedingt vertrauenerweckend ist, wenn ein Konzern wie Google alle meine jemals geöffneten Datei-Hashes und URL’s bekommen hat, bringt diese Funktion in diesem Fall eine Satte Verzögerung von 10 Sekunden.

Warum tritt das aber jetzt auf manchen PC’s auf und auf anderen nicht?

In meinem Fall steht zwischen dem PC und dem Internet noch eine Firewall und ein Proxy Server, ersterer ist unbeteiligt – aber der Proxy Server verzeichnet keinerlei Zugriffe auf die 1e100.net Domain!

Sollte er eigentlich weil alle Systeme so konfiguriert sind dass sie eine automatische Proxy Konfiguration nutzen.

Die SafeBrowsing Funktion im Thunderbird hat offenbar einen kleinen Bug, sie nutzt nicht die eingestellte Proxy Funktion! Alle Zugriffe erfolgen direkt auf das Zielsystem von Google auf Port 443 also SSL Verschlüsselt, der Proxy Server ist außen vor. Das erklärt dann auch warum er keine Einträge im Protokoll hat.

Die Lösung ist das SafeBrowsing für Downloads ab zu schalten, das erfolgt mittels folgendem Config Werts in der erweiterten Thunderbird Konfiguration:

browser.safebrowsing.downloads.enabled = false

Und schon gehen auf allen PC’s die PDF Anhänge wieder innerhalb einer Sekunde auf! 🙂

Fragt nicht wie viel Zeit mich die Suche gekostet hat…

Kategorien
Linux

Ubuntu 18.04 interface rename Problem nach Update von systemd/udev auf Version 237-3ubuntu10.26

Heute Morgen wie gewöhnlich die letzten Sicherheitsupdates von Ubuntu 18.04 installiert und einen System-Neustart eingeleitet. Was bei vielen meiner betreuten Systeme gestern ohne irgendwelche Wehwehchen über die Bühne gegangen ist, machte bei einem Firewall-System sofort Schwierigkeiten.

Keinerlei Netzwerkverbindungen waren mehr möglich, nach ein wenig Suche im System stelle sich heraus dass die interfaces nicht mehr korrekt zugeordnet waren!

Bis heute Morgen lief auf dem System systemd und udev mit folgender Versions Nummer:
237-3ubuntu10.25
Nach dem Update waren diese und ein paar weitere Pakete auf die Version
237-3ubuntu10.26
angehoben worden.

Der Fehler äußert sich im Logfile durch folgenden Meldung:

fehlerhaftes System (/var/log/syslog):
systemd-udevd[423]: Error changing net interface name ‚eth1‘ to ‚eth0‘: File exists

und hier der Log vom funktionierenden System (/var/log/syslog):
Sep 4 13:10:09 brutus kernel: [ 4.518507] igb 0000:04:00.0 rename2: renamed from eth0
Sep 4 13:10:09 brutus kernel: [ 4.565081] igb 0000:07:00.0 eth0: renamed from eth1

Ganz eindeutig fehlt hier der Rename des Interfaces eth0 bevor eth1 zu eth0 umbenannt wird, daher gibt es einen Konflikt der nicht aufgelöst werden kann und die Zuordnung der vier Netzwerkschnittstellen wird dann nicht korrekt durchgeführt.

Einen entsprechenden Bug-Report habe ich bei Canonical bereits auf gemacht:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1842651
Ihr dürft ihn gerne upvoten damit der Fehler schneller behoben wird! 🙂

In der Zwischenzeit habe ich mir durch Installation der älteren Pakete geholfen, folgende musste ich manuell herunterladen und installieren:

libacl1_2.2.52-3_amd64.deb
libsystemd0_237-3ubuntu10.25_amd64.deb
libudev1_237-3ubuntu10.25_amd64.deb
systemd_237-3ubuntu10.25_amd64.deb
systemd-sysv_237-3ubuntu10.25_amd64.deb
udev_237-3ubuntu10.25_amd64.deb

Die Installation erfolgt nach dem Download durch folgenden Befehl:

dpkg -i libacl1_2.2.52-3_amd64.deb libsystemd0_237-3ubuntu10.25_amd64.deb libudev1_237-3ubuntu10.25_amd64.deb systemd_237-3ubuntu10.25_amd64.deb systemd-sysv_237-3ubuntu10.25_amd64.deb udev_237-3ubuntu10.25_amd64.deb

Bei i386’er Systemen bitte entsprechend das amd64 durch i386 austauschen!

Anschließend lief nach einem Neustart mein System wieder korrekt, von weiteren Updates sehe ich erstmal bis zur Behebung des Bugs ab.

05.09.2019 Inzwischen wird an einem Bugfix gearbeitet, ich hoffe er funktioniert und wird bald ausgerollt!

Kategorien
Allgemein

Unifi Controller Firewall Regel-erstell Bug

Seit inzwischen etwas mehr als einem Jahr setze ich in einigen Netzwerken recht erfolgreich Hardware von Unifi und entsprechend auch deren Controller ein. Ich bin inzwischen ein kleiner Fan von der Unifi Infrastruktur, sie funktioniert gut und ist zu leistbaren Preisen verfügbar – wenn auch zeitweise nur mit längeren Lieferzeiten.

Gestern hatte ich mal wieder das „Vergnügen“ mit dem Unifi Support zu chatten, ich wollte einen vermeintlichen Bug den ich im Interface zum Erstellen von Firewall Regeln gefunden habe melden.

Was soll ich sagen, eine Stunde später war ich am Ende meiner Nerven aber irgendwie habe ich es dann doch geschafft die werte Dame davon zu überzeugen den Fehler weiter zu melden…

Der Fehler ist eigentlich schnell erklärt und nachvollziehbar – bei mir auf zwei unterschiedlichen Cloud Key’s mit ebenfalls zwei Unterschiedlichen Firmware Versionen:

Cloud Key und Controller mit der Vorversion
Cloud Key mit aktueller Firmware und Controller Version

Erstellt man eine einfache Firewall Regel welche den TCP Verkehr zu einem bestimmten Host dessen IP Adresse angegeben wird frei schaltet und speichert diese, dann erscheint nach dem Speichern im selben Dialog beim Editieren keine IP Adresse mehr. Die Regel funktioniert zwar, kann aber nicht mehr zuverlässig verändert werden.

Testregel – sämtlicher TCP Verkehr zum Server 8.8.8.8 erlauben
Nach dem Speichern wird unter Address/Port Group der Default angezeigt, IP Address ist leer.

Für den Fall dass jemand langweilig ist kommt hier noch der Mitschnitt vom Chat mit Unifi – ich hoffe es wird verständlich warum ich mich darüber geärgert habe…! 🙂

(09:17:35 AM) Manfred: Hello,
I think I found a bug!
When I crate a firewall rule wich allows all TCP traffic to a specific IP address, the IP address will be removed from the rule management interface after I save the rule.
(09:20:37 AM) Customer Service: Sorry to keep you waiting! All of our agents are currently assisting other customers, but we’ll be with you shortly! You’re welcome to explore our help center, which might have a solution for you. Take a look. https://help.ubnt.com/hc/en-us
(09:23:37 AM) Customer Service: We are experiencing unusually high support volume. We thank you for your patience and we will be with you shortly.
(09:28:25 AM) *** Anna G joined the chat ***
(09:28:30 AM) Anna G: Hi there. Let me check it for you.
(09:28:41 AM) Manfred: hi anna, please 🙂
(09:30:08 AM) Manfred: Current Version5.9.29 (Build: atag_5.9.29_11384)
(09:33:19 AM) Anna G: Which browser are you using?
(09:33:55 AM) Manfred: chrome
(09:37:16 AM) Anna G: Have you tried to clear browser history and cache?
(09:38:18 AM) Manfred: yes
(09:39:58 AM) Anna G: Please try accessing the controller in incognito mode of your chrome browser.
(09:40:29 AM) Manfred: ok, one moment…
(09:42:19 AM) Manfred: same error – after saving the ip address is empty in the field
(09:42:29 AM) Manfred: did you try that on your test system?
(09:43:34 AM) Anna G: Not yet. Please give me a moment to check this with my internal team.
(09:44:35 AM) Manfred: please create a new „wan out“ rule with accept tcp to an external ip address, save it and edit the rule again – should have an empty ip address field in destination field…
(09:50:29 AM) Anna G: On which OS is the controller installed?
(09:50:50 AM) Manfred: cloud key 🙂
(09:51:04 AM) Manfred: UCK.mtk7623.v0.12.2.ac6742e.181220.1824
(09:51:27 AM) Anna G: Have you tried rebooting the CK?
(09:52:09 AM) Manfred: no, have you tried to create a rule on your controller?
(09:53:13 AM) Anna G: Could you please reboot the CK and let me know if the issue persists?
(09:53:52 AM) Manfred: if i reboot the controller this chat will be ended or isn’t it so?
(09:54:32 AM) Manfred: to check if it’s bug or a problem on my system you would only have to do 5 clicks in the firewall settings and you could see if it happens on your site too or just on mine…
(09:55:03 AM) Manfred: I will check that on a second controller now – if the error is there too I will not have to reboot mine or?
(09:57:45 AM) Anna G: Any updates?
(09:57:55 AM) Manfred: second controller – same problem there…
(09:58:05 AM) Manfred: Visitor uploaded: after_saving.png
(09:58:06 AM) Manfred: Visitor uploaded: before_saving.png
(09:58:06 AM) Manfred: Visitor uploaded: rule_overview_with_test-rule.png
(09:58:37 AM) Manfred: would it be possible for you to check that on your test controller now?
(09:59:21 AM) Anna G: on which OS is this second controller installed?
(09:59:40 AM) Manfred: uck
(09:59:54 AM) Manfred: same version
(10:00:17 AM) Anna G: Can you please reboot this second cloud key and let me know if the issue resolves?
(10:00:32 AM) Anna G: I need to provide this information to my team.
(10:00:45 AM) Manfred: you are joking?
(10:02:38 AM) Anna G: Please check out the known issues mentioned in the release note:
https://community.ubnt.com/t5/UniFi-Updates-Blog/UniFi-Network-Controller-5-10-12-Stable-has-been-released/ba-p/2665341
(10:03:20 AM) Anna G: Refreshing/rebooting the controller should resolve any display issues reported after upgrading.
(10:05:55 AM) Manfred: i make a restart but am not really happy with the situation!
actually, i’m trying to help you identify a bug in your product and help you fix it, the easiest way would be to reproduce the problem on a test system.
the problem exists exactly the same after the restart as before.
for my part i have already spent more time to report the bug here and am a bit annoyed in the meantime.
please take this information and pass it on to your team, i will pass it on for my part on my blog.

(10:06:58 AM) Manfred: second cloud key with same problem has this cloud key version:
UCK.mtk7623.v0.12.2.ac6742e.181220.1824
(10:07:13 AM) Manfred: and controller version:
5.9.29-11384-1
(10:07:14 AM) Anna G: Thank you for the update!
(10:07:49 AM) Anna G: I will escalate this.
(10:07:56 AM) Manfred: thank you

Unifi Chat Transcript – 11.02.2019

Kategorien
Linux

Ubuntu Kernel 3.2.0-65 und Probleme mit Thunderbird/Outlook Anhängen

Vergangene Woche hat Ubuntu für die Version 12.04 LTS ein Kernel Update released – die Version 3.2.0-65. Seit Anfang dieser Woche gibts Probleme mit Anhängen im Thunderbird und Outlook – es geht extrem langsam, größere Dateien stellen die Geduld auf eine harte Probe…

Interessant dabei ist dass es nur Windows Systeme betrifft, der Zugriff vom Linux Rechner aus klappt ohne Probleme! Der Zusammenhang mit dem Kernel war nicht sofort klar, da zwischen Problem und Ursache ein Wochenende dazwischen lag und die ersten Meldungen auch erst am Dienstag eintrafen (Anwender sind teils sehr geduldig).

Nachdem die üblichen Verdächtigen ausgeschlossen werden konnten (Switch tauschen, Server neustarten) ging ich mit tcpdump auf die Suche nach der Ursache. Da das Problem nur bei Zugriffen auf extern angesiedelte Server zu finden war, vermutete ich den Fehler auf dem Transportweg dorthin.

Bei meinen Aufzeichnungen mit tcpdump fiel mir auf dass jede Menge Pakete doppelt vorgekommen sind:

09:11:16.467028 IP (tos 0x0, ttl 127, id 9284, offset 0, flags [DF], proto TCP (6), length 162)
    192.168.9.7.53479 > 192.168.1.2.993: Flags [P.], cksum 0xdabb (correct), seq 1984:2106, ack 19692, win 16263, length 122

09:11:16.773648 IP (tos 0x0, ttl 127, id 9452, offset 0, flags [DF], proto TCP (6), length 162)
    192.168.9.7.53479 > 192.168.1.2.993: Flags [P.], cksum 0xdabb (correct), seq 1984:2106, ack 19692, win 16263, length 122

Für mich sieht das nach einem Duplikat aus – im Internen Netzwerk fanden sich derlei Pakete nicht in den Aufzeichnungen.

Auf Verdacht hin habe ich dann einfach mal den Vorgängerkernel 3.2.0-64 installiert und den Firewall-Rechner der zwischen dem Server und dem Client steht neu gestartet. Und siehe da – Thunderbird funktioniert wieder einwandfrei!
Auch große Anhänge werden wieder sofort geöffnet – mit dem 3.2.0-65’er Kernel hat es zum Teil mehrere Minuten gedauert um einen 300 KB großen Anhang zu öffnen.

Damit ich das System jetzt nicht auf den alten Kernel festnageln muss und um künftige Kernel Updates umfalle, habe ich als nächstes den aktuellsten Kernel von Ubuntu 14.04 LTS ausprobiert (vom backports repository).

apt-get install linux-generic-lts-trusty

Installiert den Kernel 3.13.0 vom Ubuntu 14.04 auf dem 12.04’er System, einmal neustarten und die alten Kernel Versionen deinstallieren.

Der Fehler trat auch mit dem „trusty“ Kernel nicht mehr auf – also ein gangbarer Weg.