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.

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.

> 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. 
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.

> 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.

> 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. 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.

-- 
John M. Harris, Jr. <joh...@splentity.com>
Splentity
https://splentity.com/

_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Reply via email to