I guess there's merit for that, especially if you are in a cloud environment. In a previous company, I decided to set up dnf/kpatch for VMs that we considered critical. At the time I had a healthy disregard for reliability, mostly because we had enough trust in our terraform process so I decided to automate the whole thing through AWS System Manager across the fleet and guard the feature to work only for security patches targeting the kernel. Briefly, every VM that came up would have the necessary packages installed and from there live patching would execute periodically (I believe once a week) or manually. At some point after a quarter or something we had to devise a way to tag VMs to be excluded from this but this was relatively easy to do and most of the exclusions were testing infra anyway.
It's probably not trivial to implement and there's already a bunch of problems that need solving (e.g., trusting keys etc.) but... I think that if we had some sort of lightweight code provenance (on top of my head commits are signed from known/trusted keys, releases are signed by known keys, installing signed packages requires verification), we could probably make it somewhat harder to introduce malicious changes.
I think that depends on...how are these malicious changes actually getting into these packages? It seems very mysterious to me. I wonder why npm isn't being very forthcoming about this?
The answer to your question is WebKit (because iOS), kernels (XNU, Linux, Windows) etc. In case you are not familiar with the domain I'd start with user-space exploitation and relevant write ups to get my feet wet. You'll find plenty of write ups, blogs etc. so I'll skip those.
Some of the books I generally found interesting are [1],[2], [3]. There's more to that, including fundamental concepts of CS (e.g., compilers and optimization in JITs, OS architecture etc.). I believe also https://p.ost2.fyi/dashboard has some relevant training.
Most probably what Apple means is that since their codebase is shared, the vulnerability exists across devices. This does not mean that the vulnerability is actively exploited in iOS nor that it will not be actively exploited as part of some other campaign.
> Has this happened before? That iPhones had a security hole that could be exploited over the web?
Yes, there were exploits in the past that could be exploited remotely, including some that were used for jailbreaking.
I work as a security engineer and, yes, the CT logs are extremely useful not only for identifying new targets the moment you get a certificate but also for identifying patterns in naming your infra (e.g., dev-* etc.).
A good starting point for hardening your servers is CIS Hardening Guides and the relevant scripts.
This is honestly what scares me the most. Our biases are built in to AI, but we pretend they're not. People will say "Well, it was the algorithm/AI, so we can't change it". Which is just awful and should scare the shit out of everyone. There was a book [0] written almost fifty years ago that predicted this. I still haven't read it, but really need to. The author claims it made him a pariah among other AI researchers at the time.
I'm not a fan of Windows but Stuxnet didn't happen because of Windows. Iran decided to spin up a nuclear program and Israel and the US had concerns and wanted to stop it. They had the resources to develop something tailored for this unique situation, which included windows, Siemens PLCs (IIRC), Centrifuges etc. and developed the malware based on their target. Even if their target used a different stack, they'd find a way to achieve the same result.
It's all about price. Attacking Linux will be harder, thus more expensive.
You make it sound easy, if that was the case they'd launch one attack every few months or so. This stuff is expensive, and making it 100x harder means 100x less attacks before the budget runs out.
I'll try my best to explain everything (trying to avoid too much security lingo, hopefully).
A password manager is a big database of passwords. There is a master password that decrypts the database and from there you can use your passwords. Notice that hashes are one-way operations thus not used in password managers. The benefits of using a password manager are that that users need to remember and handle only one password, that of their password manager, the rest of the passwords are unique and can be rotated quickly. Ideally, your password manager does a few more things, including taking precautions against leaving traces of passwords in memory etc.
There's another part of commercial password managers which is mostly convenience functionality. Passwords are synced across devices, specific members access specific passwords etc.
Some people do use local password managers, depending on their threat model (i.e., who's after them) and their level of expertise/time on their hands. Setting up something locally requires taking additional precautions (such as permissions, screen locks etc.) that are typically handled by commercial password managers.
Reg. Okta, Okta is an identity provider. In theory, identity providers can provide strong guarantees regarding a user, i.e., "I authenticated him thus I gave him those token to pass around". Strong guarantees can include a number of things, including Multi-factor Authentication, VPN restrictions etc.
Funny story: during an internal red team engagement on a previous employer of mine, we took over the local password manager of a subset of the security org, twice. The first time, they had a VNC, unauthenticated, with the password manager running and the file unlocked. The second time, a team conveniently used Git to sync their password manager file, with their password tracked.
reply