Hírolvasó
[$] Microblogging with ActivityPub
As of late, concerns about the future of Twitter have caused many of its
users to seek alternatives. Amid this upheaval, an open-source
microblogging service called Mastodon has received a great deal of
attention. Mastodon is not reliant on any single company or central
authority to run its servers; anyone can run their own. Servers communicate
with each other, allowing people on different servers to send each other
messages and follow each other's posts. Mastodon doesn't just talk to
itself, though; it can exchange messages with anything that speaks the ActivityPub protocol.
There are many such implementations, so someone who wants to deploy their own
microblogging service enjoys a variety of choices.
Lina: Tales of the M1 GPU
Asahi Lina gives a detailed
update on progress toward a graphics driver for Apple M1 hardware.
There is still a long road ahead! The UAPI that we are using right now is still a prototype, and there are a lot of new features that need to be added or redesigned in order to support a full Vulkan driver in the future. Since Linux mandates that the UAPI needs to remain stable and backwards compatible across versions (unlike macOS), that means that the kernel driver will not be heading upstream for many months, until we have a more complete understanding of the GPU rendering parameters and have implemented all the new design features needed by Vulkan.
Cartier-Tilet: Emacs 29 is nigh
Lucien Cartier-Tilet looks
forward to the upcoming Emacs 29 release.
In case you didn’t know, Emacs’ current syntax highlighting is currently based on a system of regexes. Although it is not the worst thing to use, it’s not the best either, and it can become quite slow on larger files.
TreeSitter parses programming languages based into a concrete syntax tree. From there, not only can syntax highlighting can be done at high speed, but a much deeper analysis of the code is possible and actions such sa syntax manipulation can also be achieved since the syntax tree itself is available as an object which can be manipulated!
A CISA figyelmeztetést adott ki az Oracle Fusion Middleware kritikus sebezhetősége miatt
Az Egyesült Államok Kiberbiztonsági és Infrastruktúra-biztonsági Ügynöksége (CISA) egy Oracle Fusion Middleware-t érintő kritikus hibát vett fel a KEV (Known Exploited Vulnerabilities) katalógusába. A szövetségi ügynökségeknek a biztonsági frissítést 2022. december 19-ig kötelezően telepíteniük kell.
The post A CISA figyelmeztetést adott ki az Oracle Fusion Middleware kritikus sebezhetősége miatt first appeared on Nemzeti Kibervédelmi Intézet.
Figyelem: TikTok kihívást kihasználva terjesztenek káros kódot!
A Checkmarx új jelentése szerint kiberbűnözők egy népszerű TikTok kihívást kihasználva terjesztenek káros kódot.
The post Figyelem: TikTok kihívást kihasználva terjesztenek káros kódot! first appeared on Nemzeti Kibervédelmi Intézet.
Security updates for Tuesday
Security updates have been issued by Debian (frr, gerbv, mujs, and twisted), Fedora (nodejs and python-virtualbmc), Oracle (dotnet7.0, kernel, kernel-container, krb5, varnish, and varnish:6), SUSE (busybox, python3, tiff, and tomcat), and Ubuntu (harfbuzz).
[$] Yet another try at the BPF program allocator
The BPF subsystem, which allows code to be loaded into the kernel from user
space and safely executed in the kernel context, is bound to create a number of
challenges for the kernel as a whole. One might not think that allocating
memory for BPF programs would be high on the list of problems, but life
(and memory management) can be surprising. The attempts to do a better job
of providing space for compiled BPF code have, to date, only been partially
successful; now Song Liu is back with a new
approach to finish the job.
A useful guide to FFmpeg
FFmpeg is an indispensable tool for
working with
audio and video streams, but it can be challenging to learn to use well.
FFmpeg — The
Ultimate Guide, posted by Csaba Kopias, can help. "This guide
covers the ins and outs of FFmpeg starting with fundamental concepts and
moving to media transcoding and video and audio processing providing
practical examples along the way."
Security updates for Monday
Security updates have been issued by Debian (chromium, commons-configuration2, graphicsmagick, heimdal, inetutils, ini4j, jackson-databind, and varnish), Fedora (drupal7-i18n, grub2, kubernetes, and python-slixmpp), Mageia (botan, golang, kernel, kernel-linus, radare2/rizin, and xterm), Red Hat (krb5, varnish, and varnish:6), SUSE (busybox, chromium, erlang, exiv2, firefox, freerdp, ganglia-web, java-1_8_0-openj9, nodejs12, nodejs14, opera, pixman, python3, sudo, tiff, and xen), and Ubuntu (libice and shadow).
Adathalász támadások várhatóak a Twitter adatszivárgások nyomán
Egy hacker fórumon ingyenesen elérhetővé vált a júliusban még 30 000 dollárért árult, 5,4 millió Twitter felhasználó publikus és privát adatát is tartalmazó adathalom.
The post Adathalász támadások várhatóak a Twitter adatszivárgások nyomán first appeared on Nemzeti Kibervédelmi Intézet.
Több újítást is hozhat a Twitter 2.0, ilyen például az üzenetek titkosítása
A Twitter vezérigazgatója, Elon Musk hivatalosan is megerősítette, hogy a tervek szerint hamarosan érkezik a platformon küldött üzenetek végponttól végpontig terjedő titkosítása (E2EE). Mindez része a Musk által elképzelt Twiter 2.0-nak, amely a titkosított üzenetek mellett a hosszú formátumú tweeteket és kifizetés funkciót is hoz majd a felhasználóknak. A titkosított üzenetek terveiről szóló információk először […]
The post Több újítást is hozhat a Twitter 2.0, ilyen például az üzenetek titkosítása first appeared on Nemzeti Kibervédelmi Intézet.
Frissítse a Chrome böngészőt!
Vészhelyzeti frissítés érkezett a Chrome böngésző asztali verziójához, befoltozva az idei nyolcadik aktívan kihasznált zero-day sérülékenységet.
The post Frissítse a Chrome böngészőt! first appeared on Nemzeti Kibervédelmi Intézet.
Kernel prepatch 6.1-rc7
The 6.1-rc7 kernel prepatch has been
released for testing.
There is really nothing here that makes me at all worried, except that it's just a bit more than I'm comfortable with. It should just have slowed down more by now.
As a result, I'm now pretty sure that this is going to be one of those "we'll have an extra week and I'll make an rc8" releases. Which then in turn means that now the next merge window will be solidly in the holiday season.
Matthew Garrett: Poking a mobile hotspot
I've been playing with an Orbic Speed, a relatively outdated device that only speaks LTE Cat 4, but the towers I can see from here are, uh, not well provisioned so throughput really isn't a concern (and refurbs are $18, so). As usual I'm pretty terrible at just buying devices and using them for their intended purpose, and in this case it has the irritating behaviour that if there's a power cut and the battery runs out it doesn't boot again when power returns, so here's what I've learned so far.
First, it's clearly running Linux (nmap indicates that, as do the headers from the built-in webserver). The login page for the web interface has some text reading "Open Source Notice" that highlights when you move the mouse over it, but that's it - there's code to make the text light up, but it's not actually a link. There's no exposed license notices at all, although there is a copy on the filesystem that doesn't seem to be reachable from anywhere. The notice tells you to email them to receive source code, but doesn't actually provide an email address.
Still! Let's see what else we can figure out. There's no open ports other than the web server, but there is an update utility that includes some interesting components. First, there's a copy of adb, the Android Debug Bridge. That doesn't mean the device is running Android, it's common for embedded devices from various vendors to use a bunch of Android infrastructure (including the bootloader) while having a non-Android userland on top. But this is still slightly surprising, because the device isn't exposing an adb interface over USB. There's also drivers for various Qualcomm endpoints that are, again, not exposed. Running the utility under Windows while the modem is connected results in the modem rebooting and Windows talking about new hardware being detected, and watching the device manager shows a bunch of COM ports being detected and bound by Qualcomm drivers. So, what's it doing?
Sticking the utility into Ghidra and looking for strings that correspond to the output that the tool conveniently leaves in the logs subdirectory shows that after finding a device it calls vendor_device_send_cmd(). This is implemented in a copy of libusb-win32 that, again, has no offer for source code. But it's also easy to drop that into Ghidra and discover thatn vendor_device_send_cmd() is just a wrapper for usb_control_msg(dev,0xc0,0xa0,0,0,NULL,0,1000);. Sending that from Linux results in the device rebooting and suddenly exposing some more USB endpoints, including a functional adb interface. Although, annoyingly, the rndis interface that enables USB tethering via the modem is now missing.
Unfortunately the adb user is unprivileged, but most files on the system are world-readable. data/logs/atfwd.log is especially interesting. This modem has an application processor built into the modem chipset itself, and while the modem implements the Hayes Command Set there's also a mechanism for userland to register that certain AT commands should be pushed up to userland. These are handled by the atfwd_daemon that runs as root, and conveniently logs everything it's up to. This includes having logged all the communications executed when the update tool was run earlier, so let's dig into that.
The system sends a bunch of AT+SYSCMD= commands, each of which is in the form of echo (stuff) >>/usrdata/sec/chipid. Once that's all done, it sends AT+CHIPID, receives a response of CHIPID:PASS, and then AT+SER=3,1, at which point the modem reboots back into the normal mode - adb is gone, but rndis is back. But the logs also reveal that between the CHIPID request and the response is a security check that involves RSA. The logs on the client side show that the text being written to the chipid file is a single block of base64 encoded data. Decoding it just gives apparently random binary. Heading back to Ghidra shows that atfwd_daemon is reading the chipid file and then decrypting it with an RSA key. The key is obtained by calling a series of functions, each of which returns a long base64-encoded string. Decoding each of these gives 1028 bytes of high entropy data, which is then passed to another function that decrypts it using AES CBC using a key of 000102030405060708090a0b0c0d0e0f and an initialization vector of all 0s. This is somewhat weird, since there's 1028 bytes of data and 128 bit AES works on blocks of 16 bytes. The behaviour of OpenSSL is apparently to just pad the data out to a multiple of 16 bytes, but that implies that we're going to end up with a block of garbage at the end. It turns out not to matter - despite the fact that we decrypt 1028 bytes of input only the first 200 bytes mean anything, with the rest just being garbage. Concatenating all of that together gives us a PKCS#8 private key blob in PEM format. Which means we have not only the private key, but also the public key.
So, what's in the encrypted data, and where did it come from in the first place? It turns out to be a JSON blob that contains the IMEI and the serial number of the modem. This is information that can be read from the modem in the first place, so it's not secret. The modem decrypts it, compares the values in the blob to its own values, and if they match sets a flag indicating that validation has succeeeded. But what encrypted it in the first place? It turns out that the json blob is just POSTed to http://pro.w.ifelman.com/api/encrypt and an encrypted blob returned. Of course, the fact that it's being encrypted on the server with the public key and sent to the modem that decrypted with the private key means that having access to the modem gives us the public key as well, which means we can just encrypt our own blobs.
What does that buy us? Digging through the code shows the only case that it seems to matter is when parsing the AT+SER command. The first argument to this is the serial mode to transition to, and the second is whether this should be a temporary transition or a permanent one. Once parsed, these arguments are passed to /sbin/usb/compositions/switch_usb which just writes the mode out to /usrdata/mode.cfg (if permanent) or /usrdata/mode_tmp.cfg (if temporary). On boot, /data/usb/boot_hsusb_composition reads the number from this file and chooses which USB profile to apply. This requires no special permissions, except if the number is 3 - if so, the RSA verification has to be performed first. This is somewhat strange, since mode 9 gives the same rndis functionality as mode 3, but also still leaves the debug and diagnostic interfaces enabled.
So what's the point of all of this? I'm honestly not sure! It doesn't seem like any sort of effective enforcement mechanism (even ignoring the fact that you can just create your own blobs, if you change the IMEI on the device somehow, you can just POST the new values to the server and get back a new blob), so the best I've been able to come up with is to ensure that there's some mapping between IMEI and serial number before the device can be transitioned into production mode during manufacturing.
But, uh, we can just ignore all of this anyway. Remember that AT+SYSCMD= stuff that was writing the data to /usrdata/sec/chipid in the first place? Anything that's passed to AT+SYSCMD is just executed as root. Which means we can just write a new value (including 3) to /usrdata/mode.cfg in the first place, without needing to jump through any of these hoops. Which also means we can just adb push a shell onto there and then use the AT interface to make it suid root, which avoids needing to figure out how to exploit any of the bugs that are just sitting there given it's running a 3.18.48 kernel.
Anyway, I've now got a modem that's got working USB tethering and also exposes a working adb interface, and I've got root on it. Which let me dump the bootloader and discover that it implements fastboot and has an oem off-mode-charge command which solves the problem I wanted to solve of having the device boot when it gets power again. Unfortunately I still need to get into fastboot mode. I haven't found a way to do it through software (adb reboot bootloader doesn't do anything), but this post suggests it's just a matter of grounding a test pad, at which point I should just be able to run fastboot oem off-mode-charge and it'll be all set. But that's a job for tomorrow.
Edit: Got into fastboot mode and ran fastboot oem off-mode-charge 0 but sadly it doesn't actually do anything, so I guess next is going to involve patching the bootloader binary. Since it's signed with a cert titled "General Use Test Key (for testing only)" it apparently doesn't have secure boot enabled, so this should be easy enough.
comments
First, it's clearly running Linux (nmap indicates that, as do the headers from the built-in webserver). The login page for the web interface has some text reading "Open Source Notice" that highlights when you move the mouse over it, but that's it - there's code to make the text light up, but it's not actually a link. There's no exposed license notices at all, although there is a copy on the filesystem that doesn't seem to be reachable from anywhere. The notice tells you to email them to receive source code, but doesn't actually provide an email address.
Still! Let's see what else we can figure out. There's no open ports other than the web server, but there is an update utility that includes some interesting components. First, there's a copy of adb, the Android Debug Bridge. That doesn't mean the device is running Android, it's common for embedded devices from various vendors to use a bunch of Android infrastructure (including the bootloader) while having a non-Android userland on top. But this is still slightly surprising, because the device isn't exposing an adb interface over USB. There's also drivers for various Qualcomm endpoints that are, again, not exposed. Running the utility under Windows while the modem is connected results in the modem rebooting and Windows talking about new hardware being detected, and watching the device manager shows a bunch of COM ports being detected and bound by Qualcomm drivers. So, what's it doing?
Sticking the utility into Ghidra and looking for strings that correspond to the output that the tool conveniently leaves in the logs subdirectory shows that after finding a device it calls vendor_device_send_cmd(). This is implemented in a copy of libusb-win32 that, again, has no offer for source code. But it's also easy to drop that into Ghidra and discover thatn vendor_device_send_cmd() is just a wrapper for usb_control_msg(dev,0xc0,0xa0,0,0,NULL,0,1000);. Sending that from Linux results in the device rebooting and suddenly exposing some more USB endpoints, including a functional adb interface. Although, annoyingly, the rndis interface that enables USB tethering via the modem is now missing.
Unfortunately the adb user is unprivileged, but most files on the system are world-readable. data/logs/atfwd.log is especially interesting. This modem has an application processor built into the modem chipset itself, and while the modem implements the Hayes Command Set there's also a mechanism for userland to register that certain AT commands should be pushed up to userland. These are handled by the atfwd_daemon that runs as root, and conveniently logs everything it's up to. This includes having logged all the communications executed when the update tool was run earlier, so let's dig into that.
The system sends a bunch of AT+SYSCMD= commands, each of which is in the form of echo (stuff) >>/usrdata/sec/chipid. Once that's all done, it sends AT+CHIPID, receives a response of CHIPID:PASS, and then AT+SER=3,1, at which point the modem reboots back into the normal mode - adb is gone, but rndis is back. But the logs also reveal that between the CHIPID request and the response is a security check that involves RSA. The logs on the client side show that the text being written to the chipid file is a single block of base64 encoded data. Decoding it just gives apparently random binary. Heading back to Ghidra shows that atfwd_daemon is reading the chipid file and then decrypting it with an RSA key. The key is obtained by calling a series of functions, each of which returns a long base64-encoded string. Decoding each of these gives 1028 bytes of high entropy data, which is then passed to another function that decrypts it using AES CBC using a key of 000102030405060708090a0b0c0d0e0f and an initialization vector of all 0s. This is somewhat weird, since there's 1028 bytes of data and 128 bit AES works on blocks of 16 bytes. The behaviour of OpenSSL is apparently to just pad the data out to a multiple of 16 bytes, but that implies that we're going to end up with a block of garbage at the end. It turns out not to matter - despite the fact that we decrypt 1028 bytes of input only the first 200 bytes mean anything, with the rest just being garbage. Concatenating all of that together gives us a PKCS#8 private key blob in PEM format. Which means we have not only the private key, but also the public key.
So, what's in the encrypted data, and where did it come from in the first place? It turns out to be a JSON blob that contains the IMEI and the serial number of the modem. This is information that can be read from the modem in the first place, so it's not secret. The modem decrypts it, compares the values in the blob to its own values, and if they match sets a flag indicating that validation has succeeeded. But what encrypted it in the first place? It turns out that the json blob is just POSTed to http://pro.w.ifelman.com/api/encrypt and an encrypted blob returned. Of course, the fact that it's being encrypted on the server with the public key and sent to the modem that decrypted with the private key means that having access to the modem gives us the public key as well, which means we can just encrypt our own blobs.
What does that buy us? Digging through the code shows the only case that it seems to matter is when parsing the AT+SER command. The first argument to this is the serial mode to transition to, and the second is whether this should be a temporary transition or a permanent one. Once parsed, these arguments are passed to /sbin/usb/compositions/switch_usb which just writes the mode out to /usrdata/mode.cfg (if permanent) or /usrdata/mode_tmp.cfg (if temporary). On boot, /data/usb/boot_hsusb_composition reads the number from this file and chooses which USB profile to apply. This requires no special permissions, except if the number is 3 - if so, the RSA verification has to be performed first. This is somewhat strange, since mode 9 gives the same rndis functionality as mode 3, but also still leaves the debug and diagnostic interfaces enabled.
So what's the point of all of this? I'm honestly not sure! It doesn't seem like any sort of effective enforcement mechanism (even ignoring the fact that you can just create your own blobs, if you change the IMEI on the device somehow, you can just POST the new values to the server and get back a new blob), so the best I've been able to come up with is to ensure that there's some mapping between IMEI and serial number before the device can be transitioned into production mode during manufacturing.
But, uh, we can just ignore all of this anyway. Remember that AT+SYSCMD= stuff that was writing the data to /usrdata/sec/chipid in the first place? Anything that's passed to AT+SYSCMD is just executed as root. Which means we can just write a new value (including 3) to /usrdata/mode.cfg in the first place, without needing to jump through any of these hoops. Which also means we can just adb push a shell onto there and then use the AT interface to make it suid root, which avoids needing to figure out how to exploit any of the bugs that are just sitting there given it's running a 3.18.48 kernel.
Anyway, I've now got a modem that's got working USB tethering and also exposes a working adb interface, and I've got root on it. Which let me dump the bootloader and discover that it implements fastboot and has an oem off-mode-charge command which solves the problem I wanted to solve of having the device boot when it gets power again. Unfortunately I still need to get into fastboot mode. I haven't found a way to do it through software (adb reboot bootloader doesn't do anything), but this post suggests it's just a matter of grounding a test pad, at which point I should just be able to run fastboot oem off-mode-charge and it'll be all set. But that's a job for tomorrow.
Edit: Got into fastboot mode and ran fastboot oem off-mode-charge 0 but sadly it doesn't actually do anything, so I guess next is going to involve patching the bootloader binary. Since it's signed with a cert titled "General Use Test Key (for testing only)" it apparently doesn't have secure boot enabled, so this should be easy enough.
comments
More stable kernels released
Security updates for Friday
Security updates have been issued by Fedora (firefox), Mageia (dropbear, freerdp, java, libx11, and tumbler), Slackware (ruby), SUSE (erlang, grub2, libdb-4_8, and tomcat), and Ubuntu (exim4, jbigkit, and tiff).
lladdr-tied Config Support May Soon Land in ifconfig(8) and netstart(8)
It started with a thread on misc@ with the subject
"Locking network card configuration"
where the problem description is, when two or more network interfaces are attached to the same USB bus, their numbering may not be entirely predictable.
The question is, what workarounds are possible?
The thread, where several developers offered their insights, and which soon migrated to tech@ with the subject switched to "lladdr support for netstart/hostname.if (was: Re: Locking network card configuration)" and later "lladdr support for netstart/hostname.if" turned up several suggestions, with several patches, and potential support for link level address (MAC address) tied configuration via a new hostname.MAC(5) file to supplement the more familiar hostname.if(5) config file, complete with corresponding ifconfig(8) options.
Please read the messages and patches, and if you have useful input for the developers on this, please chime in via tech@ or in comments here if you prefer.
Once again, an interesting feature that may materialize for testing in snapshots in the near future.
Security updates for Thursday
Security updates have been issued by Debian (vim), Fedora (drupal7-context, drupal7-link, firefox, xen, xorg-x11-server, and xorg-x11-server-Xwayland), Oracle (container-tools:ol8, device-mapper-multipath, dotnet7.0, firefox, hsqldb, keylime, podman, python3.9, python39:3.9, thunderbird, and xorg-x11-server), SUSE (exiv2-0_26, keylime, libarchive, net-snmp, nginx, opensc, pixman, python-joblib, strongswan, and webkit2gtk3), and Ubuntu (expat, imagemagick, mariadb-10.3, mariadb-10.6, and xorg-server, xorg-server-hwe-16.04, xorg-server-hwe-18.04, xwayland).
Sharkbot malware-rel fertőztek androidos fájlkezelő appok
Nem az első alkalommal került a Sharkbot malware a Google Play áruházba. Ezúttal kiberbűnözők különböző fájlkezelő applikációba rejtve csempészték be a káros kódot a hivatalos androidos alkalmazásboltba.
The post Sharkbot malware-rel fertőztek androidos fájlkezelő appok first appeared on Nemzeti Kibervédelmi Intézet.