Hírolvasó

A LastPass szerint támadók egy korábbi, 2022. augusztusi biztonsági incidens során ellopott információk felhasználásával betörtek a cég külső fél által üzemeltetett felhő-tárhelyére. Az incidens a LastPass mellett a cég leányvállalatát, a GoTo nevű kollaborációs platformot is érintette. 

The post Adatszivárgás történt a LastPass-nál, ügyféladatok is érintettek first appeared on Nemzeti Kibervédelmi Intézet.

The OpenBSD Foundation, which is central to funding the OpenBSD project, needs your help to reach its 2022 Fundraising Goal of $300,000.

At the time of writing, the amount raised in 2022 stands at a little over 50% of the stated goal.

The Foundation needs your help to sustainably fund the project. Please head over to the Foundation's donations page, and make sure you drag your employer over there too!

With about 30 days left in 2022, we know we can do it!

Over on the Google security blog, Jeffrey Vander Stoep writes about the impact of focusing on using memory-safe languages for new code in Android. As the amount of new memory-unsafe code entering Android has decreased, so too has the number of memory safety vulnerabilities. From 2019 to 2022 it has dropped from 76% down to 35% of Android’s total vulnerabilities. 2022 is the first year where memory safety vulnerabilities do not represent a majority of Android’s vulnerabilities.

While correlation doesn’t necessarily mean causation, it’s interesting to note that the percent of vulnerabilities caused by memory safety issues seems to correlate rather closely with the development language that’s used for new code. This matches the expectations published in our blog post 2 years ago about the age of memory safety vulnerabilities and why our focus should be on new code, not rewriting existing components. Of course there may be other contributing factors or alternative explanations. However, the shift is a major departure from industry-wide trends that have persisted for more than a decade (and likely longer) despite substantial investments in improvements to memory unsafe languages.

(Thanks to Rahul Sundaram.)

The Document Foundation (TDF) was created in 2010 to steward and support the development of the LibreOffice suite, which was then a new fork of OpenOffice.org. TDF has clearly been successful; unlike OpenOffice, which is currently under the Apache umbrella, LibreOffice is an actively developed and widely used project. But TDF has also been showing signs of stress in recent years, and the situation does not appear to be getting better. There are currently some significant disagreements over just what role TDF should play; if those cannot be resolved, there is a real chance that they could rip the Foundation apart.

Security updates have been issued by CentOS (device-mapper-multipath, firefox, hsqldb, krb5, thunderbird, and xorg-x11-server), Debian (libraw), Fedora (freerdp and grub2), SUSE (bcel, emacs, glib2, glibc, grub2, nodejs10, and tomcat), and Ubuntu (linux-azure-fde and snapd).

A Lookout biztonsági cég egy új jelentésében 251 db androidos és 35 db iOS-es hitelfelvétellel kapcsolatos rosszindulatú alkalmazás került azonosításra, amelyeket összesen 15 millióan töltöttek le, főként indiai, közép-amerikai és afrikai felhasználók. Az alkalmazások időközben már eltávolításra kerültek a hivatalos alkalmazásboltokból (Google Play Store és App Store), azonban a már letöltött appokat manuálisan kell eltávolítani […]

The post Rosszindulatú kölcsönalkalmazásokkal verik át a felhasználókat first appeared on Nemzeti Kibervédelmi Intézet.

The LWN.net Weekly Edition for December 1, 2022 is available.

The recent discussion of a proposed change to the Python language—the usual fare on the language's Ideas forum—was interesting, somewhat less for the actual feature under discussion than for the other issues raised. The change itself is a minor, convenience feature that would provide a reproducible iteration order for certain kinds of sets between separate invocations of the interpreter. That is a pretty limited use case, and one that could perhaps be fulfilled in other ways, but the discussion also highlighted some potentially worrying trends in the way that feature ideas are handled in the Python community.

One of the huge benefits of WebAuthn is that it makes traditional phishing attacks impossible. An attacker sends you a link to a site that looks legitimate but isn't, and you type in your credentials. With SMS or TOTP-based 2FA, you type in your second factor as well, and the attacker now has both your credentials and a legitimate (if time-limited) second factor token to log in with. WebAuthn prevents this by verifying that the site it's sending the secret to is the one that issued it in the first place - visit an attacker-controlled site and said attacker may get your username and password, but they won't be able to obtain a valid WebAuthn response.

But what if there was a mechanism for an attacker to direct a user to a legitimate login page, resulting in a happy WebAuthn flow, and obtain valid credentials for that user anyway? This seems like the lead-in to someone saying "The Aristocrats", but unfortunately it's (a) real, (b) RFC-defined, and (c) implemented in a whole bunch of places that handle sensitive credentials. The villain of this piece is RFC 8628, and while it exists for good reasons it can be used in a whole bunch of ways that have unfortunate security consequences.

What is the RFC 8628-defined Device Authorization Grant, and why does it exist? Imagine a device that you don't want to type a password into - either it has no input devices at all (eg, some IoT thing) or it's awkward to type a complicated password (eg, a TV with an on-screen keyboard). You want that device to be able to access resources on behalf of a user, so you want to ensure that that user authenticates the device. RFC 8628 describes an approach where the device requests the credentials, and then presents a code to the user (either on screen or over Bluetooth or something), and starts polling an endpoint for a result. The user visits a URL and types in that code (or is given a URL that has the code pre-populated) and is then guided through a standard auth process. The key distinction is that if the user authenticates correctly, the issued credentials are passed back to the device rather than the user - on successful auth, the endpoint the device is polling will return an oauth token.

But what happens if it's not a device that requests the credentials, but an attacker? What if said attacker obfuscates the URL in some way and tricks a user into clicking it? The user will be presented with their legitimate ID provider login screen, and if they're using a WebAuthn token for second factor it'll work correctly (because it's genuinely talking to the real ID provider!). The user will then typically be prompted to approve the request, but in every example I've seen the language used here is very generic and doesn't describe what's going on or ask the user. AWS simply says "An application or device requested authorization using your AWS sign-in" and has a big "Allow" button, giving the user no indication at all that hitting "Allow" may give a third party their credentials.

This isn't novel! Christoph Tafani-Dereeper has an excellent writeup on this topic from last year, which builds on Nestori Syynimaa's earlier work. But whenever I've talked about this, people seem surprised at the consequences. WebAuthn is supposed to protect against phishing attacks, but this approach subverts that protection by presenting the user with a legitimate login page and then handing their credentials to someone else.

RFC 8628 actually recognises this vector and presents a set of mitigations. Unfortunately nobody actually seems to implement these, and most of the mitigations are based around the idea that this flow will only be used for physical devices. Sadly, AWS uses this for initial authentication for the aws-cli tool, so there's no device in that scenario. Another mitigation is that there's a relatively short window where the code is valid, and so sending a link via email is likely to result in it expiring before the user clicks it. An attacker could avoid this by directing the user to a domain under their control that triggers the flow and then redirects the user to the login page, ensuring that the code is only generated after the user has clicked the link.

Can this be avoided? The best way to do so is to ensure that you don't support this token issuance flow anywhere, or if you do then ensure that any tokens issued that way are extremely narrowly scoped. Unfortunately if you're an AWS user, that's probably not viable - this flow is required for the cli tool to perform SSO login, and users are going to end up with broadly scoped tokens as a result. The logs are also not terribly useful.

The infuriating thing is that this isn't necessary for CLI tooling. The reason this approach is taken is that you need a way to get the token to a local process even if the user is doing authentication in a browser. This can be avoided by having the process listen on localhost, and then have the login flow redirect to localhost (including the token) on successful completion. In this scenario the attacker can't get access to the token without having access to the user's machine, and if they have that they probably have access to the token anyway.

There's no real moral here other than "Security is hard". Sorry.

comments

It was only a matter of time before somebody found a way to inject BPF into the CPU scheduler. This patch series, posted by Tejun Heo and containing work by David Vernet, Josh Don, and Barret Rhoden, does exactly that. The cover letter covers the motivation behind this work in detail:

One of our main goals was to lower the barrier to entry for experimenting with the scheduler. sched_ext provides ergonomic callbacks and helpers to ease common operations such as managing idle CPUs, scheduling tasks on arbitrary CPUs, handling preemptions from other scheduling classes, and more. While sched_ext does require some ramp-up, the complexity is self-contained, and the learning curve gradual. Developers can ramp up by first implementing simple policies such as global FIFO in only tens of lines of code, and then continue to learn the APIs and building blocks available with sched_ext as they build more featureful and complex schedulers.

There is a bit more documentation in this patch.

Security updates have been issued by Debian (krb5), Fedora (galera, mariadb, and mingw-python3), Red Hat (389-ds:1.4, kernel, kernel-rt, kpatch-patch, krb5, and usbguard), Scientific Linux (krb5), Slackware (kernel), SUSE (binutils, dbus-1, exiv2, freerdp, git, java-1_8_0-ibm, kernel, libarchive, libdb-4_8, libmspack, nginx, opencc, python, python3, rxvt-unicode, sudo, supportutils, systemd, vim, and webkit2gtk3), and Ubuntu (bind9, gnutls28, libsamplerate, linux-gcp-5.4, perl, pixman, shadow, and sysstat).

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.

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.

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!

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.

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 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).

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.

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."