Wine: Die SSD schonen

Ihr wollt mit Wine Spiele spielen, aber Eure SSD nicht unnötig belasten? Da könnte man was machen.

Wine: Die SSD schonen

Wer auf Linux Windows Spiele zocken möchte, der kommt um Wine nicht herum. Egal in welcher Form, es ist immer irgendwie beteiligt. Leider bedeutet das auch, daß Eure SSD alleine durchs Loggen von Debuginfos belastet wird. So eine Runde WOW kann da die Lebenszeit der SSD richtig dezimieren:

# grep fixme /var/log/messages |grep „Jun 28“ | grep -c fixme
711541

meint, am 28.Juni wurden ins Logfile 711.541 Zeilen von Wine geschrieben, fast alle mit dem gleichen, leeren Inhalt:

Jun 28 10:08:21 xxx /usr/libexec/gdm-x-session[2227]: 009e:fixme:rawinput:GetRawInputBuffer data (nil), data_size 0x22f7b0, header_size 24 stub!

Von den 711k Logzeilen macht die obige Zeile 708k aus, ohne Mehrwert für den User. Rechnet Euch mal aus, wieviele das übers Jahr sind!

Wie bekommt man das jetzt weg?

Zum Glück ist das einfach in der .desktop Datei vom jeweiligen Wine-Spiel zu lösen(hier WOW):

Ändert die Exec Zeile von so:

Exec=env WINEPREFIX=“/home/<username>/.wine“ /opt/wine-staging/bin/wine64 C:\\\\windows\\\\command\\\\start.exe /Unix /home/<username>/.wine/dosdevices/c:/Program\\ Files\\ (x86)/World\\ of\\ Warcraft/_retail_/Wow.exe

in so um:

Exec=env WINEPREFIX=“/home/<username>/.wine“ WINEDEBUG=-all /opt/wine-staging/bin/wine64 C:\\\\windows\\\\command\\\\start.exe /Unix /home/<username>/.wine/dosdevices/c:/Program\\ Files\\ (x86)/World\\ of\\ Warcraft/_retail_/Wow.exe

Danach ist Ruhe im Logfile und rsyslogd bzw. journald werden Euch danken, denn:

Jun 28 16:38:51 XXXXXXX rsyslogd[1506]: imjournal: 180769 messages lost due to rate-limiting (20000 allowed within 600 seconds)
Jun 28 16:48:52 XXXXXXX rsyslogd[1506]: imjournal: 180635 messages lost due to rate-limiting (20000 allowed within 600 seconds)
Jun 28 16:58:58 XXXXXXX rsyslogd[1506]: imjournal: 103949 messages lost due to rate-limiting (20000 allowed within 600 seconds)

das, was grep da gezählt hat, ist nur das, was im Logfile auch angekommen ist. In Wirklichkeit sind da tonnenweise Logzeilen weg gefiltert worden und trotz dessen waren es am Ende noch 711k ! Das müssen mehrere Millionen Zeilen gewesen sein, an nur einem einzigen Tag!

„Warum ist das nicht die Defaulteinstellung?“ würde man zurecht fragen, aber solange nur beim Start mal kurz was wichtiges geloggt wird, ok, aber 708.010x das eine 3D-Routine gefixt werde müßte?? Also da könnte man auch mal über sinnvolleres Loggen nachdenken, oder?

Nvidia: 2 Sicherheitslücken im Linux-Treiber

Zwei Sicherheitslücken sind im NVIDIA GFX-Kartentreiber für Linux enthalten, wenn Ihr noch nicht die brandaktuellste Version haben solltet, was schwierig sein dürfte.

Nvidia: 2 Sicherheitslücken im Linux-Treiber

Laut der Bugbeschreibung bei Nvidia, handelt sich dabei bei einer Lücke um einen Bug in der IPC Communication API, was man braucht um Daten zwischen einzelnen Prozessen hin und her zu schicken. Dieser Fehler kann dazu genutzt werden um mit erweiterten Rechten eingeschleusten Code auszuführen.

CVE-IDs
Addressed
Software ProductOperating SystemDriver BranchAffected VersionsUpdated Versions
CVE‑2020‑5963
CVE‑2020‑5967
GeForceLinuxR450All versions prior to 450.51450.51
Quadro, NVSLinuxR450All versions prior to 450.51450.51
R440All versions prior to 440.100440.100
R390All versions prior to 390.138390.138
TeslaLinuxR450All R450 versionsAvailable the week of June 29, 2020
R440All versions prior to 440.95.01440.95.01
R418All versions prior to 418.152.00418.152.00

Die zweite Schwachstelle ist dann schon schwieriger auszunutzen, da eine RACE Condition ist, es kämpfen also zwei Prozesse um eine Ressource. Der Gewinn des RACE würde einen DOS erlauben. Was ein Angreifer auf einem DesktopPC davon haben würde die Grafikkarte zu crashen, naja. Ist trotzdem gut, daß es gefixt wurde.

Für Fedora lautet die Treiberversion für meine GFX-Karte 440.82 und muß daher aktualisiert werden. Da diese aus dem Repo von RPMFusion stammt, dürfte der Verbreitungsgrad und damit der Updatezwang unter Fedora/Centos/RHEL Benutzern entsprechend hoch sein. Wie das zu Problemen führen kann und was man das machen muß, lest Ihr hier: Nvidia, Fedora, RPMFusion und der Bug, der nicht sein soll.

Bei RPMFusion habe ich heute schon angeklopft, daß Updates benötigt werden.

Quelle: https://nvidia.custhelp.com/app/answers/detail/a_id/5031

Zahn der Zeit nagt am Linuxsupport von Brother

Das bislang vorbildliche Verhalten von Brother im Bezug auf Linux zeigt leider erste Schwachstellen. Kann man die Druckerfunktion über Netz noch ohne Brothertreiber realisieren, muß man für die Scannerfunktion der MFC Serien auf BRScan von Brother zurückgreifen.

Linuxsupport von Brother schwächelt zusehens

Von dem Umstand mal abgesehen, daß von Brother genutzte SAP wohl was gegen Kontaktformularanfragen hat 🙁 , sind die Webseiten von Brother was Handbücher und Treiber betrifft eigentlich ganz brauchbar. Leider kann man das von der Scansoftware nicht mehr sagen.

Die auf dem Stand 2017 kompilierte Scansoftware Brscan braucht dringend ein Update, da die verwendete libnsl u.a. von Fedora nur noch als Legacy angeboten wird und nicht mehr zum festen Systemumfang zählt. Das führt dann leider dazu, daß auch wenn man Brscan vorschriftsmäßig über das von Brother gelieferte Softwarepaket für redhatbasierte Systeme installiert, Xsane oder SimpleScan  die Scanner im Netzwerk (und vermutlich lokal auch) nicht finden.

Schuld daran ist ein „Ich hab Dir doch gesagt, ich brauche diese nsl Library“ Fehler in Brscan. Leider eskaliert das Programm den Fehler nicht an die Oberfläche, so daß der Otto-Normal-Tux keine Chance hat, da den Fehler zu finden. Dieser wird erst sichtbar, wenn ein Admin die passenden Programme von Brother direkt in der Konsole startet. Da diese Programme nicht für den Desktop geschrieben wurden, tauchen sie natürlich auch nicht im Desktop-Menü auf. Es besteht daher keine Chance, daß ein Endanwender das je findet.

Fix für Fedora u.ä.

Jetzt kann man das noch unter Fedora, und vermutlich allen anderen RH Systemen, mit dem folgenden Befehl als Rootuser leicht beheben:

dnf install -y libnsl

Es spielt dabei keine Rolle, ob Ihr Brscan vorher oder danach installiert, das Ergebnis ist das Gleiche.

Wichtig für Netzwerkdrucker ist nur, daß Ihr bei der Frage des Installationsscripts, welches auch als Root ausgeführt werden muß, die korrekte IP des Druckers/Scanners angebt. Ein Problem könnte sich dabei ergeben, wenn Euer DHCP Server im lokalen Netz dem Scanner IPs zufällig zuordnet, statt diese dauerhaft zu vergeben.

Sollte das der Fall sein, liegt eine Config Datei im /usr-Bereich der Brscan-Software, welche die IP Angabe enthält. Die müßte man dann anpassen.

Netflix, Firefox und die 1080p – Teil 3

Endlich! Das aktuelle Firefoxproblem mit der 1080p Wiedergabe von Netflix ist gelöst.

Nachdem im Truedread Build die nötigen Anpassungen bereits vor einigen Tagen gemacht wurden, konnte endlich der Pull-Request bei Vladikoffs FireFox Version eingebaut werden.

Netflix, Firefox und die 1080p

Nun müßte man das nur noch eingebaut bekommen und da haperts gerade! Es ist etwas Handarbeit nötig um das im Firefox zu installieren. Ich habe für Euch aus den Sourcen einen AddOn-Build gebaut. Damit Firefox das unsignierte Addon schluckt, muß zuerst die Signaturprüfung abgeschaltet werden.

Dazu gebt Ihr in die Addresszeile vom Firefox „about:config“ ein und sucht nach „xpinstall.signatures.required“ und ändert es auf „false“ ( einfach „true“ Doppelklicken ).

Danach könnt Ihr dann netflix_1080p-1.9.xpi ohne Probleme installieren und habt wieder 1080p Wiedergabe im Firefox. Das File heißt noch 1.9 um es mit dem aktuellen Masterstand in Übereinstimmung zu halten, aber vermutlich wird auch Vladikoff auffallen, daß er vergessen hat die Versionnummer anzuheben 🙂

Ich vermute mal, daß es in den nächsten Tagen auch einen signierten Build geben wird. Allerdings muß man dazu bei Mozilla im DevNetzwerk angemeldet sein und da habe ich keine Lust zu 🙂

Tablet: Kernel 5.6.8+ behebt USB Problem

Wer ein Surface Tablet mit Linux hat, kennt das Problem seit Kernel 5.5.8: Das Typecover konnte man nicht abziehen, weil es nicht wieder erkannt wurde, wenn man es dransteckte.

Tablet: Kernel 5.6.8+ behebt USB Problem

Ein Kernelfix in 5.6.8+ behebt das TypeCoverproblem für Linux, wie ich heute mit 5.6.11 nachweisen konnte:

Damit dürften auch andere, verwandte USB Probleme, die u.a. im Bugtracker von Redhat aufgelaufen sind, endgültig behoben sein: https://bugzilla.redhat.com/show_bug.cgi?id=1813530

Da hatten sich sogar Leute von ArchLinux gemeldet, weil Google das so schnell im RedHat Bugtracker gefunden hatte 🙂

Wie wir diesem Kommentar entnehmen können, scheint „The Big Boss“ nicht ganz unbeteiligt gewesen zu sein:

If I assume that this issue has been appeared on 5.4.23 and fixed on 5.6.8, the candidate related commits are:

  • issue introduced by commit
    torvalds/linux@8099f58
    („USB: hub: Don’t record a connect-change event during reset-resume“)
  • and fixed by commit
    torvalds/linux@9f952e2
    („USB: hub: Fix handling of connect changes during sleep“)

Wenn ich den ersten Commit richtig interpretiere, hatte da wohl beim Abschalten jemand nicht geprüft, ob er wirklich im Sleep war. Wenn man dann natürlich Geräte abzieht und das ignoriert wird, muß man sich nicht wundern, wenn man die dann nicht mehr benutzen kann. Was ich mich aber wirklich frage ist, wieso der Fix soooooo lange gebraucht hat, bis es gefixt wurde. Das ist ja schliesslich nicht nur bei Exotenhardware wie Linux-Surface-Tablets aufgefallen.

Siehe auch: https://github.com/linux-surface/linux-surface/issues/119#issuecomment-628598029

 

ClamAV < 0.102.3 mit DOS Schwachstelle

Derzeit ist kein Update für Fedora in Sicht, daher ggf. den Mailserver so umkonfigurieren, daß er keine PDF Files scannt.

Update 14.5.: die Updates für Fedora stehen bereit. Es wird aber noch etwas dauern, bis die in den Stables sind. Im Koji kann man sich die Builds für FC30-FC33 bereits ziehen. Exemplarisch für FC30, wäre das hier:

https://koji.fedoraproject.org/koji/search?terms=clamav-0.102.3-1.fc30&type=build&match=glob

Für FC30 haben wir den Build ausprobiert. er funktioniert. kann also bedenkenlos eingespielt werden.

Eilmeldung: ClamAV mit DOS Schwachstelle

Leider ist derzeit keine Fedora Version in der Mache für diese Schwachstelle:

Versionen: ClamAV < 0.102.3

In ClamAV bestehen mehrere Schwachstellen bei der Verarbeitung von bösartigen ARJ Archiven und PDF Dateien. Ein Angreifer kann dadurch den Virenscanner zum Absturz bringen. Zur Ausnutzung genügt es, eine entsprechende ARJ oder PDF Datei mit ClamAV zu scannen.

Hier die Meldung komplett:

ClamAV 0.102.3 is a bug patch release to address the following issues:

  • CVE-2020-3327: Fixed a vulnerability in the ARJ archive-parsing module in ClamAV 0.102.2 that could cause a denial-of-service condition. Improper bounds checking of an unsigned variable results in an out-of-bounds read which causes a crash. Special thanks to Daehui Chang and Fady Othman for helping identify the ARJ parsing vulnerability.
  • CVE-2020-3341: Fixed a vulnerability in the PDF-parsing module in ClamAV 0.101 – 0.102.2 that could cause a denial-of-service condition. Improper size checking of a buffer used to initialize AES decryption routines results in an out-of-bounds read, which may cause a crash. OSS-Fuzz discovered this vulnerability.
  • – Fixed „Attempt to allocate 0 bytes“ error when parsing some PDF documents.
  • – Fixed a couple of minor memory leaks.
  • – Updated libclamunrar to UnRAR 5.9.2.

Das hat wohl einige kalt erwischt, als das Bürger-CERT dazu heute eine Warnung rausgehauen hat. Ich werde Euch Informieren, wenn sich das ändert.

Quellen:https://blog.clamav.net/2020/05/clamav-01023-security-patch-released.html

 

Hacker sein leicht gemacht – Logitech Webcam

Dieser Beitrag dreht sich um Webcams von Logitech und wie man damit filmmäßig einen auf bösen Überhacker machen kann. Hacken müssen wir dabei allerdings nichts 😉

Hacker sein leicht gemacht – Logitech Webcam

Man kennt den Spruch: „Wir haben Dich beim Porno gucken gefilmt und mailen das an alle Deine Freunde, wenn Du nicht zahlst!“  Wenn der Spruch mit der üblichen Bitcoin Forderung per Mail kommt, ist er meisten nur das Übliche: eine Scammail.

Wenn eine Webcam benutzt wird, geht i.d.R. eine kleine LED an, die anzeigt, daß die Kamera benutzt wird. Hört die Nutzung der Kamera auf, geht auch das Licht aus.

Was wäre, wenn man die LED einfach .. sagen wir mal.. „abschalten“ könnte?

Was wie die Handlung eines billigen Hackerfilms klingt, ist der Horror jedes WebCam-Besitzers: Der PC wird über den Besuch einer Webseite gehackt und die Angreifer können per WebCam alles sehen und hören ohne das der Belauschte es merkt. Mal davon abgesehen, daß man auch die aktivierte LED nicht unbedingt bemerkt, wenn man nicht direkt vor der Kamera sitzt, wäre das der SuperGAU für PC Besitzer.

Wie sieht das jetzt in der Realität aus, kann man da einfach einen PC hacken, die WebCam aktivieren, den Datenstrom abgreifen und das alles ohne das die LED angeht?

Nun, wenn man Besitzer einer Logitech WebCam C310 ist, dann geht das .. fast. Das man unsichere PCs über Browser oder untergejubelte Worddokumente, Bilder, etc. hacken kann, ist ja kein Geheimnis. Erst jüngst hat AppleMail für IPhone ja so ein geile Lücke offenbart, über die man per einfacher Email ein IPhone übernehmen konnte.

Aber auch Firefox und Chrome sind alles andere als sicher und nur weil es Open-Source ist, heißt es nicht, daß es sicherer ist. Beispiel Chromium: (CVE Nummern sind gemeldete Schwachstellen in einer internationalen Datenbank)

Name        : chromium
Version     : 81.0.4044.122

Chromium is an open-source web browser, powered by WebKit (Blink).

--------------------------------------------------------------------------------
Update Information:

Another day, another chromium update. This one fixes:  CVE-2020-6458
CVE-2020-6459 CVE-2020-6460  ----  Fix dependency issue introduced when
switching from a "shared" build to a "static" build.  ----  A new major version
of Chromium without any security bugs! Just kidding. Here's the CVE list:
CVE-2020-6454 CVE-2020-6423 CVE-2020-6455 CVE-2020-6430 CVE-2020-6456
CVE-2020-6431 CVE-2020-6433 CVE-2020-6434 CVE-2020-6435 CVE-2020-6436
CVE-2020-6437 CVE-2020-6438 CVE-2020-6439 CVE-2020-6440 CVE-2020-6441
CVE-2020-6442 CVE-2020-6443 CVE-2020-6444 CVE-2020-6445 CVE-2020-6446
CVE-2020-6447 CVE-2020-6448 CVE-2020-6432 CVE-2020-6457  Oh, and this build
switches over to a static build, so the chromium-libs and chromium-libs-media
subpackages are now obsolete, but it should be slightly better for performance.

Allen Browsern sollte man mit Addons wie NoScript oder UMatrix beibringen nur das nötigste, und das auch nur auf Anweisung des Besitzers, auszuführen.

„… fast“ meinte also, daß man auch aus der Ferne angreifbar sein muß, damit einem dies passieren kann.

Hinweis: Falls Sie dies als Nicht-Linuxer lesen sollten, das geht auch unter Windows, es wird nur ein anderes Programm benutzt.

Für unseren simulierten Hack nehmen wir mal an, daß genau so eine Lücke ausgenutzt wurde. Was kommt dann als nächstes?

Gegeben ist eine Logitech WebCam C310. Wir brauchen noch folgendes Programm auf dem PC: uvcdynctrl

sudo dnf install uvcdynctrl

Als welcher User wir das Programm ausführen, scheint nicht wichtig zu sein, so lange wir mit dem Gerät reden dürfen. Bekommen wir erst einmal heraus, ob diese Kamera überhaupt da ist:

$ lsusb

Bus 010 Device 003: ID 046d:081b Logitech, Inc. Webcam C310

Jede unterstützte Kamera erzeugt ein oder mehrere Video Devices unter /dev/ :

$ ls -la /dev/video*
crw-rw—-+ 1 root video 81, 1 3. Mai 14:09 /dev/video1
crw-rw—-+ 1 root video 81, 2 3. Mai 13:47 /dev/video2
crw-rw—-+ 1 root video 81, 3 3. Mai 14:09 /dev/video3

Welches davon zu einer Logitech Kamera gehört und folglich nutzbar ist, können wir auf zwei Wegen feststellen:

$ sudo udevadm info –query=all –name=/dev/video1
P: /devices/pci0000:00/0000:00:07.0/0000:04:00.0/usb10/10-2/10-2:1.0/video4linux/video1
N: video1
L: 0
S: v4l/by-id/usb-046d_081b_5940E5D0-video-index0
S: v4l/by-path/pci-0000:04:00.0-usb-0:2:1.0-video-index0
E: DEVPATH=/devices/pci0000:00/0000:00:07.0/0000:04:00.0/usb10/10-2/10-2:1.0/video4linux/video1
E: DEVNAME=/dev/video1
E: MAJOR=81
E: MINOR=1
E: SUBSYSTEM=video4linux
E: USEC_INITIALIZED=8845895177
E: ID_V4L_VERSION=2
E: ID_V4L_PRODUCT=UVC Camera (046d:081b)
E: ID_V4L_CAPABILITIES=:capture:
E: ID_VENDOR=046d
E: ID_VENDOR_ENC=046d
E: ID_VENDOR_ID=046d
E: ID_MODEL=081b
E: ID_MODEL_ENC=081b
E: ID_MODEL_ID=081b
E: ID_REVISION=0010
E: ID_SERIAL=046d_081b_5940E5D0
E: ID_SERIAL_SHORT=5940E5D0
E: ID_TYPE=video
E: ID_BUS=usb
E: ID_USB_INTERFACES=:0e0100:0e0200:010100:010200:
E: ID_USB_INTERFACE_NUM=00
E: ID_USB_DRIVER=uvcvideo
E: ID_PATH=pci-0000:04:00.0-usb-0:2:1.0
E: ID_PATH_TAG=pci-0000_04_00_0-usb-0_2_1_0
E: ID_FOR_SEAT=video4linux-pci-0000_04_00_0-usb-0_2_1_0
E: COLORD_DEVICE=1
E: COLORD_KIND=camera
E: DEVLINKS=/dev/v4l/by-id/usb-046d_081b_5940E5D0-video-index0 /dev/v4l/by-path/pci-0000:04:00.0-usb-0:2:1.0-video-index0
E: TAGS=:seat:uaccess:

Eine UVCVideo Kamera, so wie die Logitech C310 eine ist, ist ein starkes Indiz. Das es auch genau unsere gesuchte Kamera ist, das zeigt ein Vergleich der USB ID …

Bus 010 Device 003: ID 046d:081b Logitech, Inc. Webcam C310

… welche sich oben wiederfindet: Gotcha!

Methode 2 wäre dann unser kleines Tool einzusetzen, um sich alle WebCams auflisten zu lassen und dann vergleichen wir wieder die USB ID:

$ uvcdynctrl -l
[libwebcam] Invalid V4L2 control type encountered: ctrl_id = 0x00980001, name = ‚User Controls‘, type = 6

video1 UVC Camera (046d:081b)
Media controller device /dev/media1 doesn’t exist
ERROR: Unable to list device entities: Invalid device or device cannot be opened. (Code: 5)

Kamera gefunden, was kann die?

Wir haben jetzt also die richtige Kamera identifiziert, fragen wir mal was die Kamera so „anbietet“:

$ uvcdynctrl -d /dev/video1 -vc

Listing available controls for device /dev/video1:
Brightness
ID : 0x00000001,
Type : Dword,
Flags : { CAN_READ, CAN_WRITE },
Values : [ 0 .. 255, step size: 1 ],
Default : 128
Contrast
ID : 0x00000002,
Type : Dword,
Flags : { CAN_READ, CAN_WRITE },
Values : [ 0 .. 255, step size: 1 ],
Default : 32
Saturation
ID : 0x00000004,
Type : Dword,
Flags : { CAN_READ, CAN_WRITE },
Values : [ 0 .. 255, step size: 1 ],
Default : 32
White Balance Temperature, Auto
ID : 0x00000009,
Type : Boolean,
Flags : { CAN_READ, CAN_WRITE },
Values : [ 0 .. 1, step size: 1 ],
Default : 1
Gain
ID : 0x00000003,
Type : Dword,
Flags : { CAN_READ, CAN_WRITE },
Values : [ 0 .. 255, step size: 1 ],
Default : 0
Power Line Frequency
ID : 0x0000000d,
Type : Choice,
Flags : { CAN_READ, CAN_WRITE },
Values : { ‚Disabled'[0], ’50 Hz'[1], ’60 Hz'[2] },
Default : 2
White Balance Temperature
ID : 0x00000008,
Type : Dword,
Flags : { CAN_READ, CAN_WRITE },
Values : [ 0 .. 10000, step size: 10 ],
Default : 4000
Sharpness
ID : 0x00000007,
Type : Dword,
Flags : { CAN_READ, CAN_WRITE },
Values : [ 0 .. 255, step size: 1 ],
Default : 24
Backlight Compensation
ID : 0x0000000c,
Type : Dword,
Flags : { CAN_READ, CAN_WRITE },
Values : [ 0 .. 1, step size: 1 ],
Default : 1
Exposure, Auto
ID : 0x0000000f,
Type : Choice,
Flags : { CAN_READ, CAN_WRITE },
Values : { ‚Manual Mode'[1], ‚Aperture Priority Mode'[3] },
Default : 3
Exposure (Absolute)
ID : 0x00000011,
Type : Dword,
Flags : { CAN_READ, CAN_WRITE },
Values : [ 1 .. 10000, step size: 1 ],
Default : 166
Exposure, Auto Priority
ID : 0x00000010,
Type : Boolean,
Flags : { CAN_READ, CAN_WRITE },
Values : [ 0 .. 1, step size: 1 ],
Default : 0
LED1 Mode
ID : 0x046d0003,
Type : Choice,
Flags : { CAN_READ, CAN_WRITE, IS_CUSTOM },
Values : { ‚Off'[0], ‚On'[1], ‚Blink'[2], ‚Auto'[3] },
Default : 3
LED1 Frequency
ID : 0x046d0004,
Type : Dword,
Flags : { CAN_READ, CAN_WRITE, IS_CUSTOM },
Values : [ 0 .. 131, step size: 1 ],
Default : 0

Kurz zur Erklärung der Auflistung, folgendes sind Optionen die wir in der Kamera ändern können, solange diese Option den FLAG „CAN_WRITE“ hat aka. Schreibrecht :

„Brightness“, „Contrast“, „Saturation“, „White Balance Temperature“, „Auto,Gain“ ,“Power Line Frequency“, „White Balance Temperature“, „Sharpness“, „Backlight Compensation“, „Exposure, Auto“, „Exposure (Absolute)“ , „Exposure, Auto Priority“,  „LED1 Mode“, „LED1 Frequency“

Schau wir uns den „LED1 Mode“ an:

LED1 Mode
ID : 0x046d0003,
Type : Choice,
Flags : { CAN_READ, CAN_WRITE, IS_CUSTOM },
Values : { ‚Off‚[0], ‚On‚[1], ‚Blink‚[2], ‚Auto‚[3] },
Default : 3

Im Normalfall steht also die LED Anzeige auf Automatik, meint, das Licht geht automatisch an und aus.

Jetzt nutzen wir diese Kontrollen

Fragen wir die Cam doch mal, welchen Zustand sie derzeit hat:

$ uvcdynctrl -d /dev/video1 -g „LED1 Mode“ 2>/dev/null
3

„3“ ist der Automatikmodus.

Einschalten der LED geht so:

$ uvcdynctrl -d /dev/video1 -s „LED1 Mode“ 1 2>/dev/null

Ausschalten geht so:

$ uvcdynctrl -d /dev/video1 -s „LED1 Mode“ 0 2>/dev/null

Wer das ausprobiert, wird feststellen, daß beim permanenten Einschalten die LED erstmal nur für einen Moment angeht. Es handelt sich bei der „Kontrolle“ um den Zustand der LED im Betriebsfall, da die WebCam aus ist, geht das Licht gleich wieder aus. Probiert das mal aus, wenn Ihr Camorama oder eine Videokonferenz laufen habt.

Das bedeutet, daß wenn Ihr die LED vor dem Aktivieren der Webcam abschaltet, bleibt die aus, auch wenn die Kamera aktiviert wird und das ist genau der Zustand den ungebetene Gäste auf Eurem PC ausnutzen möchten. Jetzt kann ein Angreifer seine Software zur Ansteuerung der Kamera natürlich gleich so schreiben, daß die LED aus bleibt, wenn er die Kamera aktiviert. Es muß dafür nicht das „uvcdynctrl“ installieren oder vorfinden. I.d.R. kann der Angreifer die Bordprogramme nicht direkt benutzen um den Inhalt der WebCam nach außen zutransportieren, da diese Programme ein Fenster öffnen um das Bild dem PC-Nutzer anzuzeigen.

Es ist aber natürlich auch möglich, sowas wie FFMPEG zu benutzen um das Bild abzugreifen und gleich zu komprimieren und an einen Server zu senden. Je weniger Software der Angreifer selbst installieren muß, desto besser für ihn, da er weniger Spuren hinterläßt.

Beweise

Jetzt kann der Typ von dem Blog ja viel behaupten, es ist an der Zeit das zu beweisen:

LED an

und abschalten:

LED aus

Das es sich hier um einen Browser handelt dürfte leicht erkennbar sein. Das Bild ist meine 1-Mann Videokonferenz auf unserer Jitsi Meet Instanz, in der man mein Handy bei der Aufnahme der LED sehen kann.

Mit „ucview“ kann man sich diese Kontrollfunktion auch live ansehen und ändern, ohne die Konsole bemühen zu müssen:

ucview Kontrollen der C310

 

Merkwürdigkeiten bei der Logitech WebCam C310

Merkwürdig ist der Fakt, daß die Kontrollen für die LED nicht beim ersten Starten der WebCam angeboten werden. Dazu muß die WebCam scheinbar ein zweites mal initialisiert werden, den Treiber neu starten hilft dabei:

sudo rmmod uvcvideo
sudo modprobe -v uvcvideo

Auf dem von mir heimtücksich infiltrierten Test-PC meiner Eltern war dies z.B. nötig 😉

Ob es sich dabei um einen Bug in der Kamera handelt oder im UCVideo Treiber von Linux, mag ich nicht beurteilen wollen. Möglich wäre jede Version oder auch gleich beides zusammen.

Meinung

Die Funktion der Kamera zum Abschalten der LED mag vielleicht in den Augen der Entwickler witzig oder sogar nützlich gewesen sein, aber aus Sicht der Privatsphäre ist das natürlich ein NO-GO. Anwendungen die die Kamera nach belieben einschalten können, ohne das der User überhaupt die Chance hat, dies zu bemerken, sind ein ernstzunehmendes Risiko. Daher sollte diese WebCam immer abgeklebt, oder besser komplett abgestöpselt sein, wenn Sie nicht benutzt werden.

Wenn der ganze Coronawahnsinn durch ist, lege ich mir definitiv eine neue Webcam ohne diese Funktion zu. Vermutlich was im 8-12 MP Bereich 😀

Linux: grep Magie

Geht es Euch auch so auf den Senkel, das, wenn man grep benutzt um in minifizierten Dateien etwas zu suchen, die ganze Datei ausgegeben wird, weil grep als Ergebnis die ganze (eine) Zeile ausgibt?

Ich präsentiere: Das Ende vom Minifizierungsergebnis

Für alle Linux Neulinge, mit grep kann man Dateien, meistens Text, aber nicht notwendigerweise, nach Suchbegriffen durchsuchen. Beispiel:

# grep ErrorLog /etc/httpd/sites/vhosts
ErrorLog logs/error_log
ErrorLog logs/error_log
ErrorLog logs/error_log
ErrorLog logs/error_log
#

Man sieht, das in der Datei vhosts 4x der Begriff ErrorLog in vier verschiedenen Zeilen vorkommt. So weit, so gut.

Was aber, wenn es nur eine einzige Zeile in dem zu durchsuchenden Textblock/Datei gibt?

Damit Ihr das nachvollziehen könnt, hier eine kurze Anweisung:

# wget „https://ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js“
–2020-04-14 22:57:08– https://ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js
Auflösen des Hostnamens ajax.googleapis.com (ajax.googleapis.com)… 2a00:1450:4007:811::200a, 216.58.204.138
Verbindungsaufbau zu ajax.googleapis.com (ajax.googleapis.com)|2a00:1450:4007:811::200a|:443 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 200 OK
Länge: nicht spezifiziert [text/javascript]
Wird in »jquery.min.js« gespeichert.

jquery.min.js [ <=> ] 90,92K –.-KB/s in 0,07s

2020-04-14 22:57:08 (1,33 MB/s) – »jquery.min.js« gespeichert [93100]

Das Ergebnis des obigen Befehls ist eine Datei in Eurem Verzeichnis, die „jquery.min.js“ heißt. Schaut Sie Euch mit einem Texteditor an und Ihr werdet sofort verstehen um was es geht.

Suchen wir darin etwas, sagen wir das Wort „function“, was in einer Javascriptdatei häufig vorkommen sollte, erhalten wir lediglich die Zahl „3“ als Ausgabe:

# grep -c function jquery.min.js
3
#

Das liegt daran, daß es in der ganzen Datei nur 3 „Zeilen“ gibt, in denen das Wort vorkommt. Bisschen wenig für JQuery, dem Javascriptframework oder? Schauen wir mal:

# grep function jquery.min.js

Wie man sehen kann, kommt das Wort „function“ da deutlich mehr als dreimal vor und es wird einem praktisch die gesamte Datei ausgegeben, statt nur anzuzeigen, was um den Suchbegriff drumrum ist, wie das bei einer zeilenbasierten Formatierung ( siehe erstes Beispiel ) der Fall wäre. Mit anderen Worten: Je nachdem wie groß die minifizierte Datei ist die man durchsucht, desto mehr völlig unnötigen Zeichensalat bekommt man als Ergebnis, was einem nicht weiterhilft.

Bis jetzt!

Jetzt sagen wir mal grep, daß es nur die Zeichen um das Suchergebnis herum ausgeben soll:

# N=10; grep -roP „.{0,$N}function.{0,$N}“ jquery.min.js
(function(e,t){var
=f.trim,x=function(e,t){retu
-z])/gi,H=function(e,t){retu
Case()},q=function(e){(a.add
ady())},_=function(){a.addEv
or:x,init:function(e,n,r){va
0,toArray:function(){return
his)},get:function(e){return

und siehe da, es werden viel, viele, sehr viele Treffer vom Wort „function“ ausgegeben, jede mit „Kontext“ darum.

Das funktioniert so

„N=10;“ setzt vor dem grep Befehl die Variable N auf 10, was am Ende meint „+- N Zeichen um den Suchbegriff“
„grep -roP“ sucht (-r) rekursiv, (-o) zeige nur den Suchbegriff an und (-P) benutze Reguläre-Suchausdrücke von Perl.
„.{0,$N}function.{0,$N}“  meint jetzt: 0-Nx beliebige Zeichen + „function“ + 0-Nx beliebige Zeichen

Also bekommen wir die obige Ausgabe, weil neben dem was wir suchen vorn und hinten noch maximal 10 beliebige Zeichen zum Suchbegriff zählen. Wer dem jetzt nicht folgen kann, aber interessiert ist, sollte nach „Reguläre Ausdrücke“ googeln und eifrig studieren. Reguläre Ausdrücke, auch Regex genannt, sind eine mächtige Sprache zur Musterformulierung.

Damit können wir jetzt beliebige minifizierte Dateien nach sinnvollem Kram durchsuchen, ohne unsinnig viel Müll zu bekommen.

Security Update: Firefox 75 ist da

Da hatten wir quasi gestern erst die Meldung, daß wir uns 74.0.1 updaten müßten und schon müssen wir auf Firefox 75.0 updaten, weil auch in der 74.0.1 ein Sicherheitsloch von der Größe New Yorks klafft 🙁

Security Update: Firefox 75 installieren

Hier könnt Ihr Euch vorab die Firefox Versionen für Eurer Fedora ziehen:

https://kojipkgs.fedoraproject.org//packages/firefox/75.0/1.fc30/x86_64/firefox-75.0-1.fc30.x86_64.rpm

https://kojipkgs.fedoraproject.org//packages/firefox/75.0/1.fc31/x86_64/firefox-75.0-1.fc31.x86_64.rpm

https://kojipkgs.fedoraproject.org//packages/firefox/75.0/1.fc32/x86_64/firefox-75.0-1.fc32.x86_64.rpm

Die Installation ist dann ganz einfach, wenn Ihr mit der Konsole im Downloadverzeichnis seid:

sudo dnf update ./firefox-75*rpm

Ein Doppelklick per Dateiexplorer geht natürlich auch, dann öffnet sich die Softwareverwaltung und fragt Euch nach dem Rootpasswort und schon wird es auch so installiert.

Der erste Eindruck ist leider „AAAAARGGGS!“ weil die Adressleiste wird jetzt abartig groß! Das sieht so dämlich aus!

Linux: 190GB RAM erwünscht ..

Da heißt es immer, Linux wäre so Ressourcenschonend .. mu har har har..auf dem Papier, ok 🙂

190 GB RAM erwünscht

Vorhin glitschte bei mir kurz die TOP Anzeige durch, da fielen mir folgende Angaben auf:

3294 marius 20 0 9,9g 1,0g 53144 S 0,7 6,7 2:18.47 java
2767 marius 20 0 3658568 703720 157848 S 1,3 4,3 8:02.93 thunderbird
4718 marius 20 0 3611796 622464 245956 R 2,7 3,8 41:28.36 firefox
3061 marius 20 0 5029712 561352 140764 S 0,3 3,4 36:38.85 skypeforlinux
2636 marius 20 0 1404048 516784 55476 S 0,0 3,2 0:48.15 gnome-software
2577 marius 20 0 3878152 293020 103852 S 0,0 1,8 8:53.58 cinnamon
6285 marius 20 0 2848784 275648 178572 S 0,0 1,7 1:06.03 Web Content
1713 gdm 20 0 2882496 222756 105604 S 0,0 1,4 0:11.92 gnome-shell
4961 marius 20 0 2721516 222324 147568 S 0,3 1,4 1:35.18 Web Content
2601 marius 20 0 98,4g 201364 73168 S 0,0 1,2 0:22.12 liferea
9771 marius 20 0 2612880 192700 127616 S 0,0 1,2 0:23.12 Web Content
10910 marius 20 0 2607960 187556 129964 S 3,3 1,1 0:19.45 Web Content
4900 marius 20 0 2627124 185064 106852 S 0,0 1,1 1:11.14 WebExtensions
2998 marius 20 0 935120 177228 90376 S 0,0 1,1 1:38.35 skypeforlinux
11932 marius 20 0 2581276 174744 129216 S 0,0 1,1 0:13.21 Web Content
4833 marius 20 0 2688600 172948 117520 S 0,0 1,1 1:31.50 Web Content
2603 marius 20 0 2899340 167280 99908 S 0,3 1,0 1:18.97 skypeforlinux
2090 root 20 0 431540 157632 127032 S 0,3 1,0 10:22.48 Xorg
2418 marius 9 -11 2493616 104560 16004 S 1,3 0,6 25:37.16 pulseaudio
3151 marius 20 0 82,4g 98896 77908 S 2,7 0,6 8:23.59 WebKitWebProces

rechnet man das zusammen, gehen alleine diese drei Prozesse davon aus, daß sie zusammen 190GB brauchen werden. Tun sie natürlich nicht 🙂 Zum Glück, weil das Mainboard nur maximal 32 GB könnte 😉

Wieder „Zum Glück“ sind dies nur die virtuelle Speicherblöcke. Denkbar wäre allerdings, daß ein manipulierter RSS Server, Liferea erkennt und einfach GBweise RSS Daten an den Prozess schickt, bis das System zu Tode geswappt wurde.

Für Liferea schauen wir mal in die pmem Tabelle rein:

15655: /usr/bin/liferea –gapplication-service
000055cbe8e92000 112K r—- liferea
000055cbe8eae000 284K r-x– liferea
000055cbe8ef5000 144K r—- liferea
000055cbe8f1a000 16K r—- liferea
000055cbe8f1e000 4K rw— liferea
000055cbe8f1f000 4K rw— [ anon ]
000055cbe99bf000 110760K rw— [ anon ]
00007f8800000000 33554432K rw— [ anon ]
00007f9000000000 33554432K —– [ anon ]
00007f9800000000 16777216K rw— [ anon ]
00007fa23c000000 132K rw— [ anon ]
… 2 Kilometer mehr an Speicherblöcken entfernt..

33G+33G+16G = 82G

Die rechtlichen 16 GB möchte er dann doch für den „Rest“ verbraucht wissen .. naja.. Ich geh mal davon aus, daß der Entwickler K mit M verwechselt hat und eigentlich 100 MB Ram haben wollte, was für LifeRea auch 99M zuviel gewesen wären 😉 Ich erwähne das eigentlich nur, weil das nicht erst seit gestern so ist: I wish

Wieso allerdings der WebKit Prozess da auch 82.4GB Ram haben wollte, entzieht sich mir jetzt. Die anderen WebKitProzesse waren mit viel weniger zufrieden.