Is even that needed? Nothing e2ee about the emails you receive normally, they could just read them right away if they really wanted to. And that is to say nothing about the metadata.
I keep reading about how IoT / wearables / smart home devices are routinely both vulnerable and exploited, if not even come with malware preinstalled, so I was curious to finally go through a primary source like this.
After skimming through the attacks performed in this research, and checking every mention of the word "internet", all I got was a section with a hypothetical scenario where the watch has a publicly reachable IPv4 address. Suffice to say, that is really quite unlikely, certainly in my experience at least.
It did also talk about bundled malware, so I guess that's bad enough, but is all IoT research like this? Always sounded to me like you kinda need to already have a foot in the door for these, and this paper didn't dispel that notion for me at all.
Many of the great hacks have involved breaking through 2 layers of supposed security. You break into the 3D printer, which lets you send packets on the local network. Then you use that to break into the exercise bike, which has a camera because it's based on a generic tablet.
Either vendor might see the flaw as low-severity. So what if someone can send packets? So what if someone already on the local network can hack the camera? But combine them and you're pwned.
"You're safe as long as every device on the network you're on is safe" isn't safe.
In theory I should be able to take a modern browser/device over a completely compromised router and either be safe, or have my device tell me "holy shit, something is wrong".
The days of local trust should be long gone by now.
> a hypothetical scenario where the watch has a publicly reachable IPv4 address
Or one of your other IoT / smart home devices / malware on your PC is doing local network reconnaissance? Connecting this device to a public wifi? Or just a bad neighbour who hijacks your SSID? This smells of "I'm secure because I'm behind a NAT" which conveniently ignores the couple dozen other paths an adversary could take.
I can materialize that smell for you, you're indeed more secure because you're behind NAT. Admitting this does not necessarily entail:
- suggesting that it's a good security solution
- suggesting that it's a security solution to begin with
- suggesting that it somehow prevents all avenues of remote exploitation
What it does do is make these stories sound a lot less dramatic. Because no, John Diddler is not going to be able to just hop on and get into your child's smartwatch to spy on them from the comfort of their home on the other side of the world at a whim, unlike these headlines and articles suggest at a glance. Not through the documented exploitation methods alone anyways, unless my skim reading didn't do the paper justice.
Remaining remote exploitation avenues do include however:
- the vendor getting compromised, and through it the devices pulling in a malicious payload, making them compromised (I guess this kinda either did happen or was simulated in the paper, but this is indirect and kind of benign anyways; you implicitly trust the vendor every time you apply a software update since it's closed source)
- the vendor being a massive (criminal?) doofus and just straight up providing a public or semi-public proxy endpoint, with zero or negligent auth, through which you can on-demand enumerate and reach all the devices (this is primarily the avenue I was expecting, as there was a car manufacturer I believe who did exactly this)
- peer to peer networking shenanigans: not sure what's possible there, can't imagine there not being any skeletons in the closet, would have been excited to learn more
List not guaranteed complete. But this is the kinda stuff I'd be expecting when I see these headlines.
Sure. Or you might step out the door and a fridge falls on you. Equally likely.
Yes, it's an exploit. It should be fixed. But the endless hyperventilating over fringe exploits mostly has the effect that people now ignore all security conversations.
The source site/paper won't load for me at this time, but if the device has a cellular modem in it for network connectivity, it will 100% be assigned an IPv4 address from the carrier. Unless this device is using an APN at the carrier level, or is using a SIM provider that provides some additional security.
Sure, but that’s increasingly likely to be a private IPv4 address as a result of:
Carrier-grade NAT (CGN or CGNAT), also known as large-scale NAT (LSN), is a type of network address translation (NAT) used by Internet service providers (ISPs) in IPv4 network design. With CGNAT, end sites, in particular residential networks, are configured with private network addresses that are translated to public IPv4 addresses by middlebox network address translator devices embedded in the network operator's network, permitting the sharing of small pools of public addresses among many end users. This essentially repeats the traditional customer-premises NAT function at the ISP level.
You must not be in the United States. Here, regular home cable/fiber internet ISPs usually assign a (dynamic) public ipv4 address to your router. Your cellular internet connection is usually behind cgnat, both on your phone and the new home wireless internet from the cellular providers, but regular home cable/fiber internet is the most common home internet type.
So I agree that the watch would likely be behind NAT (for IPv4), I just disagree with the statement that ISPs usually put their customers behind cgnat.
For age verification and identity verification both afaik. Sometimes I wonder if what's needed is "just" a more public push for it, but these topics are so hopelessly technical, I think it has no hope to ever reach the mainstream and poll well. And that is ignoring all the other counterarguments against these that compound on top, some of which are culturally sensitive for many.
I saw a presentation about this 6 months ago, it looked promising for age verification for example, it's even an already done system, not a research article.
These topics are political and I seriously doubt these types of solutions are what the politicians are looking for. In fact, they are the exact opposite of what they are looking for because it takes away the excuses they are using and would lay bare what they are actually trying to do. BTW, I'm not suicidal and I bet you aren't either.
Agreeable comments will draw comparatively fewer replies, while disagreeable ones achieve the opposite.
But this then results in a "false experience" for the individual, where unlike in real life, the bad exchanges do not end up outweighed by the good ones, as you simply don't go on to have those. You just upvote and move on (often to avoid redundancy).
Maybe if the two were tied together (voting either up / down & sending a reply), communities would work healthier? I don't know. Not like it's easy to have this tried out.
I could definitely see challenges to this though, the aforementioned redundancy being one. I have some countermeasure ideas, but then I wonder if that would make the UX complicated enough to drive people away instead, which is a lose-lose.
Because that's the first layer that deals with user accounts, and subsequent layers commonly base off of identity information stored in there. Just like how and why every other shared interface exists.
I thought it is by introducing an RCE vulnerability that you get an RCE vulnerability.
I'm being facetious of course, but this recent rhetorical trend of people confidently vouching for "pet" in "pet vs. cattle" is not a sustainable decision, even if it's admittedly plain practical on the short to medium run, or in given contexts even longer. It's just a dangerous and irresponsible lesson to blindly repeat I think.
Change happens. Evidently, while we can mechanistically rule out several classes of bugs now, RCEs are not one of those. Whatever additional guardrails they had in place, they failed to catch this *. I think it's significantly more honest to place the blame there if anywhere. If they can introduce an RCE to Notepad *, you can be confident they're introducing RCEs left and right to other components too **. With some additional contextual weighting of course.
* Small note on this specific CVE though: to the extent I looked into it [0], I'm not sure I find it reasonable to classify it as an RCE. It was a UX hiccup, the software was working as intended, the intention was just... maybe not quite wise enough.
** Under the interpretation that this was an RCE, which I question.
> * Small note on this specific CVE though: to the extent I looked into it [0], I'm not sure I find it reasonable to classify it as an RCE. It was a UX hiccup, the software was working as intended, the intention was just... maybe not quite wise enough.
Most people seem to see "CVE" and "RCE" and assume the worst here. As you saw though, Notepad is just making totally valid URIs clickable! Web browsers allow it too - why is it not an RCE there? Sure, they usually show a warning when the URI is going to something external but most people just click through things like that anyway.
> This Notepad vuln, allows you to click things like ssh://x....
Which just opens up SSH connecting to a server. Is that really RCE?
It'll also only work with URI schemes that are registered on your system. It's not running arbitrary commands - software you install on your PC registers URI schemes and sets what command it should run when opened. It's then up to that software to parse the URI and handle it properly. If it doesn't then the RCE belongs to them because they registered the URI scheme and failed to handle it securely. Having an allowlist of URI schemes in Notepad isn't going to fix it.
As far as I can tell there is no URI scheme registered on Windows for JScript, PowerShell, or VBScript. They have file associations but those are not URI schemes.
> According to the CVSS metric, the attack vector is local (AV:L). Why does the CVE title indicate that this is a remote code execution?
> The word Remote in the title refers to the location of the attacker. This type of exploit is sometimes referred to as Arbitrary Code Execution (ACE). The attack itself is carried out locally.
> For example, when the score indicates that the Attack Vector is Local and User Interaction is Required, this could describe an exploit in which an attacker, through social engineering, convinces a victim to download and open a specially crafted file from a website which leads to a local attack on their computer.
The low level tool that has served to rescue more systems than I can count does not need to "change" simply because "it happens, bro."
> while we can mechanistically
You can rule it out with process as well. As in "don't change what isn't broken."
> If they can introduce an RCE to Notepad
Then they clearly feel they have no viable competition. This is table stakes. Getting it wrong should lose you most of your customer base overnight. Companies actually used to _work_ this way.
If I told you to stop using computers, and then you won't have computer problems, I don't think you would find that particularly helpful or charitable either, would you?
What you find a trusty "low-level" tool is a demo application for a basic WYSIWYG text editor. They modernized it so that it remains being perceived that way, instead of letting it be increasingly misclassified as a legacy product for the enthusiast, like you just did.
That was my first thought... Notepad is a plain text editor. Why add formatted text options when there's no good reason for it?
Plus, judging by the image, it doesn't look like there's controls to interact with the plain text markdown. It seems more like it's a "you can use markdown _codes_ to trigger text formatting. Jira has exactly this, and it's horrible.
But this is not about how you, but Microsoft, "the corporation that turns updates into chaos,"introduces RCE bugs. And bugs in general: easy to introduce, by action or inaction, when one has absolutely no concern for user satisfaction.
It comes from the world of systems operations. Something long-lived and trusted, so high emotional attachment (pet), vs. something short-lived that thus does not need to be trusted, so comparatively low emotional attachment (cattle).
For example, Bob's one-of-a-kind trusty server from which Bob is nigh inseparable, vs. a Docker container with a version controlled config you routinely tear down and bring up instances of, maybe even in an automated fashion.
Here this would map to trusty aged codebases you don't touch out of fear and caution, vs. codebases you can confidently touch because the spec, the code, the tests, the tooling, and the processes are solid.
A different mapping: to Microsoft, the users's computers are cattle, but to each individual user, the computer is a pet. Which is why the users keep getting mad when their pet feature gets euthanized.
Pets are projects that you toy with and keep adding new features, even when the main objective has been met.
Cattle are projects that do what they are supposed to and are left alone.
I'd much rather have Notepad fall into the cattle category.
reply