But most software that would need to care about that already needs to care about timezones, and those already need to be regularly updated, sometimes with not much more than a month's notice.
Was this Morsy's government or Sisi's? If it's Morsy's government you're holding a grudge against, I have some good news for you. (Presumably you're not holding that grudge against random taxi drivers and housewives in Alexandria.)
I don't know if the level of bureaucracy where that decision was made is really impacted by the leadership changing. Egypt continues to make super short notice timezone changes as recently as last year. (Just at least not 3 days notice this most recent time around)
As I'm sure many of the customers can tell you, the company and the products are very real. And they come in very real milled aluminum cases, the case in the images is 3d printed because it's a prototype.
I don't understand the initial motivation for converting regular dynamic library dependencies to dlopen dependencies. How does that help with reducing the footprint?
It makes the presence of those libraries optional: you no longer need them to execute the relevant tool at all. It'll just mean you can't use features which depend on those libraries. For libraries that are only pulled in for less-commonly used features it makes a lot of sense (the specific case they are doing it for is generating the initrd, which needs a copy of any libraries used by anything running in the initrd, which is almost always going to include systemd, but the systemd in the initrd is very unlikely to use any of these optional features)
I think it's also relevant that the xz exploit made use of the fact that by running code before main, they could modify areas of memory that later get turned read-only. Any library that does get loaded with dlopen can of course still attack the process it's in, but it has less tools available to it for evading detection.
The specific way sshd was infected would not have happened with libxz as dlopen library.
Debian's sshd only uses libsystemd for the notify api. I.e. it doesn't need any feature that uses libxz. If it's dlopen()ed, it does not need to be loaded into the process context to use an unrelated feature.
FWIW, IMO upstream systemd should split their monolithic library and allow users to pick better that way, but this has other implications on DX.
> FWIW, IMO upstream systemd should split their monolithic library and allow users to pick better that way, but this has other implications on DX.
FWIW, upstream systemd has the opinion that no-one should load the library for startup notification, instead they should use the well documented api and just write a message to a socket.
Indeed, that's what the Debian maintainer of OpenSSH did soon after the quick security fix. He replaced the dependency on libsystemd with some hand-made code that notifies systemd by socket.
https://salsa.debian.org/ssh-team/openssh/-/commit/cc5f37cb8...
That's not what they said in their update to the documentation[0] last week, which says that "although using libsystemd is a good choice, this protocol can also be reimplemented without external dependencies".
It calls it a "good choice". Did they say somewhere else that no-one should do it despite it supposedly being a good choice?
sshd should not have used libsystemd in the first place for the trivial notification. And the ifunc stuff is its own security nightmare. Papering over this by dlopen-ing some libs in libsystemd does not address the deeper issues.
> What you gain is that the vulnerabilities will be harder to track down?
No, they're just as easily tracked.
What you gain is that you can refuse to install optional dependencies because they are now optional when they used to be required.
That's a fairly big deal.
Of course, in practice all those optional dependencies will be installed anyways because of other things in the distro needing them. You can fairly object that not much changed, at least for now.
A better approach would be to eliminate a lot of these dependencies somehow. Another approach would be to sandbox the dependencies that cannot be eliminated.
Though only with this particular approach to the backdoor. If systemd had always had this approach (or distros hadn't patched sshd to link it in), the attackers would have focused on a different path from delivering malicious code to widely-used distros which executes in a priviledged context to network RCE.
Wouldn't this systemd feature add a convenient centralized point of attack to inject libraries? Not as open at the user level, but similar to a LD_PRELOAD kind of vulnerability.
Not in a way that isn't otherwise accessible, IMHO. I mean, if you're really concerned about injected vulnerabilities into high-trust software (and you should be!) you should be suspicious of any dynamic linkage at all. But if you're going to do it, doing it late and under affirmative control is almost certainly the right choice.
It's because of how dynamic linking/loading works on Linux. An ELF dependency means that symbols in the library can override symbols in the binary or in other libraries. That doesn't work when the library is loaded with dlopen().
That’s the essence of consumerism, isn’t it? "how to milk out users as much as we can" (with variation around "milk gently lot of users" or "milk hard a few addicted junkies", with everyone dreaming of being Apple "milk really hard a lot of addicted junkies")
WAF always sees unhashed passwords -- passwords are sent TLS encrypted in a POST body (unhashed) and are hashed by the server software -- and that's regardless of the password policy.
There are various schemes where the password is salted, hashed or prehashed on the client side, to various effectiveness. They have never been really popular and the advent of ubiquitous https probably made them even less common, but they do exist. They do help protect you from your own WAF though.
can you elaborate on this? Or link something that does? My intuition is that whatever gets sent over the wire is effectively the password. Not sure how the server could validate some rolling hash of the password (based on like a timestamp or something) without having to store the pre-image(i.e. the raw password).
The SRP Authentication and Key Exchange System does not send the password from the client to the server. This scheme is supposedly used by Blizzard when authenticating users in some of their online games.
Yes, that's the common counter argument. Your hash has now just become the password, and no amount of clever salting really solves that.
It still prevents the server (and any proxies, MitM attackers, etc) from seeing the plain-text password, which can help protect the user if they reused the password somewhere else. Assuming the client wasn't also compromised, which is very likely in web applications but maybe a valid scenario in apps and desktop applications.
The other imho valid idea is that you can run a key derivation function client-side (e.g. salted with the user-name), in addition to running your normal best-practice setup server side. This can allow you to run more expensive key derivation which provides more protection if your database is leaked, while also making dictionary attacks on your authentication endpoints less viable.
If your password is 123456, then client-side hashing will make this less obvious. If the site is compromised in a way that reveals passwords, then it will not trivially work on other sites that use your password. In addition, stronger total hashing can be used, since if your server can do M hashes persecond and your client can do N hashes per second, the total number of hashes to allow a one second login are (M/$NUMBER_OF_CONCURRENT_LOGINS)+N which is strictly larger than (M/$NUMBER_OF_CONCURRENT_LOGINS).
SRP[1] is an even better improvement, where an eavesdropper cannot authenticate as you; there is a challenge-response to login.
These are SQL commands. The WAF would see the password unless you pre-hash it on the client side in JavaScript (not a bad idea). But the database really should never ever see the plaintext password. If it does you're doing a lot more wrong than just being open to SQL injection.
Mandatory naming systems are pretty common around the world. Many countries, for example, have a list of permitted given names, and requirements around what family name can be used (e.g father's name, if father is known).
Polish does this for some local last names, mostly the ones ending with "ski" (they end with "ska" for a female)[1]. This makes grammatical sense, Polish adjectives change their form depending on the gender of the noun they apply to, and those names are kind of sort of adjective like.
Czech goes even further and applies grammatical rules to all names, even foreign ones. Czech news broadcasters will literally say "Melania Trumpova" or "Michelle Obamova".
Incidentally, those gendered forms are a pain in the ass to deal with in user interfaces, particularly if you don't have gender information for your users and/or want to support nonbinary, something slavic languages are really not designed to do.
[1] The US doesn't enforce this rule of course, and therefore it's not unusual to meet a female American with Polish roots with the surname "Kaminski" (or sometimes even "Cumminskey").
>The US doesn't enforce this rule of course, and therefore it's not unusual to meet a female American with Polish roots with the surname "Kaminski" (or sometimes even "Cumminskey").
Also it's a common choice for translators of books written in those languages to give female characters the masculine versions of their surnames so readers won't be confused about who is related to who. Perhaps an extreme example is that some English translations of a particular Tolstoy novel have the title Anna Karenin.
Hah! I'm not sure about this. It could, but it also could help with language preservation.
I was quite surprised when GPT-4 was able to talk in Lojban to me. Somehow, I doubt it was intentionally trained to speak Lojban - that's a pretty niche conlang. So, I guess, it possibly picked some on its own, just from the books and dictionaries that were fed to it?
And to my amusement, it said that it doesn't speak Lojban, but can talk in the languages from my custom instructions... to my very limited understanding, all in mostly correct Lojban (except that it used "glico" ["English" in the sense of culture] instead of "glibau" ["English" in the sense of language]). Maybe it doesn't speak it well, but certainly does much better than I.
