--=-cfsO3KWBNvAHvICgDo7l
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Hi list, 

I think his example is not the best, but the entire idea is great: 1024
root-ports and the rest is a battle-field should be depreciated. I think
its easy (except of one thing ;)  ) to implement sth like a "secbind"
protocol into NetBSD:

A Userspace-programm ( maybe with /etc/secbind.conf and startable via
/etc/rc.conf ) giving you the chance to enable a more secured bind in
the kernel. The design could be that on a bind(), the UID and GID is
first checked for permission to bind to that port. Users can only bind
to granted ports, which is interesting for shell-providers and admins
have remote/local access granted to others but don't want them to start
any network services. It should also be possible to implement a password
function to allow more-priviledged users to bind() to other ports. The
only thing would be howto make it backward-compatible ( GENERIC-kernels
would not have it enabled by default due philosophy incompatibility )
without excluding/including it statically, e.g. *just* implement the
"old" bind() *or* the "secbind()" ... . I mean it would be very nice if
the administrator could decide what to use without recompiling a kernel.

What do you think about the general idea ?

What do you think about the only problem I pointed out already ?


With best regards,


Sascha Retzki

--=-cfsO3KWBNvAHvICgDo7l
Content-Disposition: inline
Content-Description: Weitergeleitete Nachricht - [Rosiello Security]
	Negligent architecture for the assignment of the ports
Content-Type: message/rfc822

	<vuln-dev-return-6705-sascha.retzki=t-online.de@securityfocus.com>
	mailin03.sul.t-online.de with esmtp id 1BH7Tz-0MQrNA0; Fri, 23 Apr 2004
	22:41:11 +0200
	[205.206.231.19]) by outgoing.securityfocus.com (Postfix) with QMQP id
	E79E2143751; Fri, 23 Apr 2004 21:43:33 -0600 (MDT)
Mailing-List: contact vuln-dev-help@securityfocus.com; run by ezmlm
List-Id: <vuln-dev.list-id.securityfocus.com>
List-Post: <mailto:vuln-dev@securityfocus.com>
List-Help: <mailto:vuln-dev-help@securityfocus.com>
List-Unsubscribe: <mailto:vuln-dev-unsubscribe@securityfocus.com>
List-Subscribe: <mailto:vuln-dev-subscribe@securityfocus.com>
Date: 23 Apr 2004 16:54:43 -0000
Message-ID: <20040423165443.6179.qmail@www.securityfocus.com>
Content-Type: text/plain
Content-Disposition: inline
MIME-Version: 1.0
From: Angelo Rosiello <angelo@rosiello.org>
To: vuln-dev@securityfocus.com
Subject: [Rosiello Security] Negligent architecture for the assignment of
	the ports
Content-Transfer-Encoding: 8bit



Probably, this could be a known problem for some system administrators(some people said it, but I couldn't find any clear mechanism relating my idea..), so this advisory is for who doesn't know the following attack.
Moreover no default possible solution is adopted by any operating system then I decided to inform you.

                Copyright © 2004 Rosiello Security 
                     http://www.rosiello.org
Abstract
This advisory shows that it is possible for a user to catch a port which is/was owned by another user, which represents an opportunity for malevolent attacks. 

I. BACKGROUND
I'm going to face the problem with a practical approach in order to give a clear idea of the essence of the problem. Then, this kind of attack can be extended on every software which is near, as working mechanisms, to the following shown example. 

My choice was irc bouncers and/or irc bots. 

Irc bouncers are used as gateway to connect on irc servers. There are lots of advantages that you can obtain using this programs like the possibility to use an host different from your real one to connect on the irc server. Bouncers, in fact, should protect you against DoS attacks and similar actions. 

II. DESCRIPTION
Exploiting default settings of the bouncers(port listener, banners, response messages and so on), it is possible to simulate its interactions with the users in order to obtain the password of the victim. 

III. ANALYSIS 
To exploit this opportunity the attacker should know and/or own the following information:

1) the port of the victim's bouncer;
2) the response messages of the victim's bouncer;
3) an account on the same machine of the victim;

The attacker could code a simulator of the bouncer used by the victim, listening on the same port. Since the port is busy because used by the victim's bouncer, the simulator will not run, but this is not a problem. 
If the machine has got a crontab it's enough to put the simulator under crontab with the lowest range of time (e.g. trying to run the simulator every minute). When the machine will be rebooted or the victim's bouncer will crash, the attacker's fake bouncer will run correctly. 
When the user will log into the bouncer, he will send his personal data that will be logged, then the simulator will die. Now, the victim's data are stolen. When the victim will try to log into the original program again, probably the real bouncer has been loaded. However his data are stolen. 

IV. DETECTION
Many of the most known operative systems are vulnerable by default. It's not a software bug but, personally I think it's negligence in the design(in the small) of the architecture for assigning the ports.

The main victims could be shell providers or internet services sellers. 

V. FIX
The problem exists because users can catch any port (but the root's ones) of the machine.
The solution, proposed by Rosiello Security, is to assign a range of ports for each user, it is done by a lkm named fixbind. 

Abstraction of the problem with logical mathematics of the first order: 

A1. base_port = first_port+(step*uid) => base_port-1 < port_range < base_port+step

A2. assign_port(uid, port) <=> base_port-1 < port < base_port+step && uid < 555 

This is not "the solution" but just a proof of concept to show how it's possible to manage the SYS_bind call. The uid<555 is a design choice too.
Don't mail me with critics about the fix...My purpose wasn't to code a fix.
One can download this pof from http://www.rosiello.org/archivio/fixbind.c 

VI. TIME LINE 
Discovery: 05.01.2004
Fix: 12.04.2004
Public disclosure: 16.04.2004 

VII. CREDITS 
Angelo Rosiello 
angelo@rosiello.org 

Rosiello Security
http://www.rosiello.org 


--=-cfsO3KWBNvAHvICgDo7l--