socket

Latest response

hi,
let`s say that an application that listen on a port has a network socket.
the socket listen on interfaces for i/o traffic -not the application listen on port for traffic.right?
the port is bind to the socket.
if the socket is owned by root -a socket is a file-then if a hacker will have access to that socket then the hacker will receive the root privilege?
tnx

Responses

How sockets work

An application opens a socket() and gets a file descriptor in return. UNIX/Linux has applications treat their external I/O as reads and writes into a file descriptor, which simplifies the concept of application programming. Once a file descriptor is open, there is no difference doing I/O to/from a network socket, a file on disk, a terminal, etc.

The socket is opened with a specific address family, and the address family translates into the underlying protocol used (eg: AF_INET, SOCK_STREAM is an IPv4 TCP socket). I'll assume you're talking about TCP here.

The application can optionally choose to bind() the TCP socket to an address/port, then either connect() out or listen() for incoming connections. Incoming connections must be accept()ed which creates a new file descriptor just for that stream, and this accepted stream translates to a TCP connection with a tuple.

The listening for data (protocol data or payload data) on all of these sockets is done by the kernel, which handles the protocol-level stuff for the application. For example, the application doesn't need to worry about the TCP handshake - the kernel performs this then raises a socket notification to the application when the successfully-handshaken stream is waiting to be accepted. Likewise the application doesn't need to worry about the SEQ/ACK or segmentation into individual packets or TCP Retransmissions - the kernel peforms this and the application treats the socket file descriptor as a simple byte stream.

Malicious activity

Talking about privilege escalation gets more complicated.

Ports under 1024 are bind-restricted either to the root user, or to users with CAP_NET_BIND_SERVICE Linux capability. Most applications which bind to these low-numbered ports will either use capabilities, or will bind to the port as root and then drop permissions back to their own non-priv user.

If you have a malicious party somehow opening low-numbered ports then what other control they have depends on the method they use to gain access to the system in the first place.

If the attacker has taken over or replaced a binary with CAP_NET_BIND_SERVICE then they probably don't have root access.

If the attacker has taken over or replaced a binary which is allowed to become root, the attacker potentially does have full root access.

If you have a specific report of this or wish to query more details, please do contact Red Hat Product Security at secalert@redhat.com.