Interesting. If that’s possible (I haven’t tested it, but I’m sure it is) then you wouldn’t even need to log the password. You could just alias sudo to a bash script that runs your malicious payload using the real sudo. Then the user would run the command, be prompted for their password by the real sudo, and be none the wiser that a malicious script has just been executed
For what it’s worth, Windows’ security model says it’s not an exploit that programs can grant themselves admin rights if the user is an admin (https://github.com/hfiref0x/UACME). But afaik Linux doesn’t have that model so it is a bit of an issue that this is possible
It’s literally in the opening post you replied to:
> A local privilege escalation to root via an exploitable service?
> Doesn't Linux have one of these CVEs...each week?
Why else would people be talking about docker, and user/group ownership of running services, and so on and so forth, in response to their comment and yours?
- the discussion was about how Defender might have “root” access but Linux services have CVEs too.
The reason Defender has elevated access is precisely because it needs to do stuff like hook into file system events and scan files irrespective of their underlying ACLs.
So it’s not the same as desktop anpplication exploit that would be running as the same user/group as the person logged in. And it’s also not the same as any other type of service, be that a RDBMS, web server, IRC server, nor any other type of server you might think off.
In fact this is true for both Windows AND Linux. Your average service will not have access to read user files and desktop applications are not services running as root.
I get you’re trying to make a balanced argument. And I do agree that Linux has had a great many poorly thought out design decisions (and even more problems inherent from its POSIX lineage). But the specific arguments you’re making in this thread are just misinformed and misunderstand how these operating systems work.
Except as a kid back then, the screensaver was trivial to install and neat to look at, and BOINC was a pain. I dropped it when they switched. I imagine some less-technical adults who were interested did as well.
Agreed, although the reimbursement should be based on whether a reasonable person could consider that to be a vulnerability. Often it’s tricky for outsiders to tell whether a behaviour is expected or a vulnerability
Rubbish. That analogy is like comparing a gun manufacturer to a hitman service.
Elon Musk is willingly allowing Grok to be used to harass women (and children). He could easily put in safeguards to prevent that, but instead he chooses to promote it as if its a good thing.
Practically no one defends websites that host AIs to remove clothing from photos of women, or put them in bikinis. The few people who do defend them are usually creeps who need their hard drive searched. Same goes for anyone defending this
I just hope Apple will fast track a UX update... but they probably won't, due to sunk cost fallacy, and the market and design trends will follow them.
This happens every time, a redesign comes out and people hate it. Same when iOS flat design came out. I dug into the archives, because HN has been around for a while now so we can do that, yay!
(hand picking / editing comments freely because I can)
> I read article after article from historically pro-Apple bloggers/authors explaining that no, flat design was fundamentally a bad move: the strongest metaphor is that of the phone as a tool -- that we needed skeumorphism, we need hints for interactivity, we needed polish.
> I think iOS 7, on the whole, looks worse than iOS 6. The stock icons look outright ugly; interfaces like the call-answer screen and the calculator look poorly designed, and everything has the sense that it just needs another run or two through the review process.
> Look at his iMessage screen comparison [1]: yes, the old screen looks a bit geocities, but you can actually read text very well; the new screen is almost unreadable. The prime aim of iMessage is to make people read text, not to look cool.
> Hopefully I'm not the only one that thinks this is going to kill usability. The reason old people can figure their way around <=iOS6 is that everything that can be tapped looks like a button. A more "mature" audience isn't what apple's good at appealing to.
> I'm volunteering at a center that teaches senior citizens various computer skills. One of the courses we teach is on how to use their iPhones. I'm dreading the moment that iOS7 is released: all of these people are going to have to start right back at the beginning in their understanding.
"Attack vectors" is a very interesting choice of words. Yt-dlp is literally using a public API for its intended purpose (accessing videos). The only difference is how yt-dlp is delivering the videos to the user. Probably as much of an "attack" as user-agent spoofing or using browser extensions.
But to answer your question, no, there aren't any suitable APIs (I've looked into it). They all either require JavaScript (youtube.com and the smart tv app) or require app integrity tokens (Android and iOS). Please let me know if you know something I don't?
Youtube’s tv app is actually just a website (youtube.com/tv, although you need a tv user agent). So yeah, I think most tvs are using JavaScript and the rest are using the tvlite api which has less formats than web_safari (which will continue to work in yt-dlp without Deno if you’re willing to accept 1080p downloads with inferior codecs)
They have been using the older APIs kept around for the benefit of those smart TVs for a very long time, but things move on and newer TVs get fancier hardware and more full-featured software, which includes YouTube, and so Google has started proactively dropping support.
For what it’s worth, Windows’ security model says it’s not an exploit that programs can grant themselves admin rights if the user is an admin (https://github.com/hfiref0x/UACME). But afaik Linux doesn’t have that model so it is a bit of an issue that this is possible