On Tuesday, August 27, 2019 9:14:10 AM MST Björn Persson wrote: > John Harris wrote: > >On Tuesday, August 27, 2019 5:36:20 AM MST Björn Persson wrote: > >> Please elaborate. Where does the script come from, what exactly happens > >> by accident, and how would a packet filter stop it? > > > >It could come from anywhere, that's not the point. A *firewall* would stop > >it from doing anything too harmful: Opening up the system to the world by > >binding a port, or listening on a UDP port. > > If it could come from anywhere, then we must assume that it's malicious. > You executed untrusted code. It's already past your firewall. Game over, > you're infected. You're closing the stable door after the horse has > bolted. > > >It'd still be bound, or would still be listening on a port, but it wouldn't > >be accessible unless somebody went and manually opened a port on the > >firewall. > And what if the malicious script doesn't just listen, but actively > phones home? > > >> A badly written script accidentally starts some network service that it > >> doesn't need? The one time that actually happens, the user will likely > >> click "allow" without thinking, as they will have been accustomed to > >> doing so all the time. > >> > >> > >> If the script actually needs to listen on the network, then the user > >> will have to allow it, and the script is no less badly written than it > >> was before. > > > >There is no "allow" button. I don't know what you're talking about. > > Let's just say I'm talking about granting permission with Polkit like > you mention below, whichever way you envision that. > > >Additionally, I'm referring to incidents like that common in node.js, where > >a package gets modified to something malicious, and then runs a backdoor > >which is accessible over a given port. > > Again, it's already past your firewall. You're already infected. What > if the malicious Javascript doesn't just run a backdoor, but actively > phones home? > > >> How would a "vulnerability" "bind a port"? If the program is supposed > >> to communicate, then it will be allowed, and any vulnerabilities it has > >> are then exposed to the network. If it's not supposed to communicate, > >> then it won't randomly sprout a network service because of a bug. > > > >For example, RCEs, specific or otherwise. This has happened in `firefox` > >before. > > OK so you meant the case below: > >> If you mean that an arbitrary code execution vulnerability has been > >> exploited, so that the program is now executing the attacker's code, > >> then it's already too late. The attack code won't listen for incoming > >> connections. It will make an outgoing connection to its master. And in > >> case you're considering requiring permission even for outgoing > >> connections – which would be unbearable to the user – the attack code > >> would just make an API call (through Dbus or whatever) to grant itself > >> permission to communicate. > > > >Just because a potential attacker may have already compromised part of a > >system doesn't mean that you just open up the firewall to anything they've > >got listening. > > And for the fourth time: It's not listening, it's actively phoning home. > > >Additionally, such a thing trying to open a port would likely > >require Polkit to grant you permission to do so first, which would, by > >default, require the user to authenticate and have the appropriate > >permissions. > > Do you expect users to type their passphrase every single time they > want to play some peer-to-peer game, or make an Internet phone call, or > download something with Bittorrent, et cetera? > > Or would the permissions be stored permanently somewhere? In that case, > how would you prevent a malicious program from impersonating one of the > permissioned programs? > > Björn Persson This isn't "secure" or "not secure". If your home got robbed while you were out, would your solution be to leave your doors unlocked from then on? That's what this is suggesting. -- John M. Harris, Jr. <johnmh@xxxxxxxxxxxxx> Splentity https://splentity.com/ _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
