Surprised to see no patch available for watchOS, which can also receive images via iMessage. Not important enough to patch, or not vulnerable, or just not exploited in the wild yet?
I was hoping this would work over ssh in a macOS Terminal.app, but last I tried it was inserting all kinds of weird characters into the edited text files.
Windows ships an official OpenSSH server these days, but so far there haven't been any good official text editors that work over OpenSSH, as far as I know.
I've had to resort to "copy con output.txt" the few times I needed to put things into a text file over windows-opensshd...
If linux kernel security really is so bad that google had to add a proof-of-work to introduce a 4 second race for 0day submissions, I'm surprised they're ok with still using the Linux kernel as the base for Android.
Also, attack surface reduction is a very valid strategy, so it may seem like about the userspace (sandbox for every apps etc) but it could make a big different in how much of the kernel attack surface is exposed.
Yes, but the concept of CFI is only mentioned in passing in that entire thread, and the kCFI implementation used is a vanilla kernel feature and not android specific.
There's a lot to be said that "Distro kernel config choices may not be as secure as possible", but that's not really an "Android"/"Vanilla Linux Kernel" difference.
I'd argue that the entire point of using a shared open source kernel is that other users can benefit from additions.
Arguing "Who first added a feature" seems to be a losing spiral of needless tribalism. How many features does the Android kernel use that weren't developed by Google? Does that mean they wouldn't have developed those features? Or just that there's no point making a parallel implementation if there's already one existing.
The point here is not who first added the feature to Linux kernel. The point is Android cared about security, built a CFI implementation, started shipping it back in 2018, while Linux had other priorities and didn't have it until 2021. And even then almost nobody adopted it.
What is the alternative? I suspect all modern kernels are more or less just as vulnerable? They did start https://fuchsia.dev/ so maybe they are hedging against this problem? But making a fully-featured OS is a huge undertaking, especially if you need compatibility with existing apps and a wide variety of hardware.
What's the alternative that is efficient, feature complete(*) and more secure?
(*) For example, Android uses SELinux to confine apps, virtual machines (pKVM) to run DRM code, and so on. All these increase the overall security of the system and decrease the cost of kernel bugs, so there's a tradeoff that's not easy to evaluate.
Google isn't doing the race thing. They just pay out to whoever submits a valid submission. The people doing the racing are the submitters who want to get ahead of their competition and are stockpiling their exploits. If they were altruists, they would just submit their exploits for no renumeration. Hence the race isn't something Google is doing.
The proof of work isn't there to add a "four second race". It's to prevent ddos like spam.
And just a tip, if you don't have any Apple devices but need to test a bug/inconsistency being reported by Safari users, you can usually use GNOME Web (Epiphany) and the same behavior will usually manifest, since it is a true Webkit browser. It also includes the Web Inspector with the exact same interface as Safari. And it's not super outdated or anything like that, it tracks Webkit quite well nowadays.
It's a bit ironic that Webkit started as KHTML, a component of KDE, but eventually made its way to GNOME when a Gecko-based Epiphany became hard to maintain.
So I guess you couldn't get certificates for any random (MX) domain, only for those where you can obtain an inbox / user account. Still really bad, especially for things like gmail.com, but also larger enterprises. Intense.
It is unlikely that SSL.com would issue a certificate for any major mail host; it would be malpractice for them not to have some kind of exclusion list.
Issuing a Google certificate is a good way to get your whole CA killed.
Sure, gmail.com might be excluded, but its still a massive hole for a few reasons.
This would affect ANY email provider who offers public email addresses. While I agree gmail.com is probably excluded (and maybe this doesn't bypass CAA -- maybe it does) there's a whole additional surface of anyone who has an email at any big enterprise getting a certificate for their domain.
Even if I work at google.com, therefore have a google.com email, I should absolutely not be able to get a certificate for google.com just by getting an email at that company.
I doubt it's even /that hard/ to buy an email account at a big company like that in the underground world, it seems like they are valuable generally and any company with 200k employees is going to have some leaks. This massively increases the attack surface of a simple leaked email account (which might otherwise have very little or no access).
Crazy crazy oversight that has huge implications and is so easy to carry out that I would not be surprised if this was actually exploited by bad actors.
Or any domain for which you can read an email sent to an inbox. I remember a few years ago an attack where the attacker would read email because a ticket would be created for incoming emails, and he could guess the next ticket ID to read it. A lot of platform that aren't email providers still allow emails in (e.g. GitHub, GitLab). This looks like a rather widely-applicable attack.
I couldn’t reproduce the attack with a pair of my own domains, so I think it might be even narrower in scope than the initial post suggests. But I suppose we will just have to wait to see what the CA says.
> Out of an abundance of caution, we have disabled domain validation method 3.2.2.4.14 that was used in the bug report for all SSL/TLS certificates while we investigate.
I saw this on twitter a few hours ago on my phone, and misread the price as $25, so I was considering maybe putting in an order or even two, but when I revisited the site on my laptop and discovered it was $250, my curiosity hit a wall. Looks like a super neat product but unfortunately a bit overpriced for a gimmick.
I recently ran into an issue with this because building an iOS .ipa from the command line with xcodebuild apparently ends up shelling out to call rsync to copy some files between local directories, and because I had homebrew rsync earlier in $PATH, it would end up running homebrew rsync, but xcodebuild passed an openrsync-only command line argument "--extended-attributes" that homebrew rsync doesn't understand and would exit with a failure.
Probably because the 6502 CPU had instructions for optimized access to the zero page (first 256 bytes of RAM), this would also apply to C64 and NES etc. If you want to use "Indirect Indexed" memory accesses then I think it also has to go through an address held in the zero page.
The AVR architecture puts its registers starting from address 0 of its data memory. As a twist, the program memory also starts at 0 (due to the Harvard architecture).
I think I read somewhere that scammers set up an email distribution list / alias / forwarding from one something.onmicrosoft.com account to dozens of victims, and then they trigger a (real!) paypal email with that one something.onmicrosoft.com address as the recipient. So the email has a valid DKIM signature from paypal, then microsoft forwards that email to all the victims, which will still pass DKIM while amplifying the attack (and maybe boosted by microsoft's SPF reputation as well) to hit as many people as possible. Apparently the paypal emails are real but dangerous as they will allow the attacker to somehow take over the victim's account if they log in, as the "middleman" onmicrosoft.com alias then becomes associated with the account which was the original "to"-email from paypal. Something like that, at least.
Messages pass DMARC because they originate at paypal servers (and have valid DKIM) but O365 abused to spread these messages and MS doing little to stop abuse.
Most email providers support mail forwarding and distribution lists, but maybe they should have added some sort of opt-in confirmation when adding recipients outside the local domain...?
I usually avoid logging in to xcode. I prefer to manually configure provisioning profiles and code signing certificates by hand in the developers.apple.com web interface anyways. You can use xcodebuild on the command line to get a signed ipa, and then you can use altool or application loader to upload the ipa to appstoreconnect. I don't trust xcode to not stomp all over my carefully configured provisioning profiles and app ids.
I have never once trusted xcode to get provisioning profiles and certificates right.
It's always manual for me, at least that way xcode won't suddenly tell my app is not registered to a team and refuse to build.
I know it's not relevant to the discussion, but I want to voice publicly how much I loathe the build error system in XCode. How can they possibly think anyone will find their obtuse and downright impossible log system is helpful.
