One of the Intel server platforms has a magic port number (623) that
it uses for remote server management. However, neither the kernel nor
glibc are aware of this special port.
As a result, when someone requests a privileged port using
bindresvport(3), they may get this port back and bad things happen.
Has anyone run into this or similar problems before ? Thoughts on
what's the right place to handle this issue ?
-Arun
Le sam 16/11/2002 ? 01:00, Arun Sharma a écrit? :
> One of the Intel server platforms has a magic port number (623) that
> it uses for remote server management. However, neither the kernel nor
> glibc are aware of this special port.
>
> As a result, when someone requests a privileged port using
> bindresvport(3), they may get this port back and bad things happen.
>
> Has anyone run into this or similar problems before ? Thoughts on
> what's the right place to handle this issue ?
run a dummy app at startup which reserves that port ?
[email protected] (Xavier Bestel) writes:
> Le sam 16/11/2002 ? 01:00, Arun Sharma a écrit? :
> > One of the Intel server platforms has a magic port number (623) that
> > it uses for remote server management. However, neither the kernel nor
> > glibc are aware of this special port.
> >
> > As a result, when someone requests a privileged port using
> > bindresvport(3), they may get this port back and bad things happen.
> >
> > Has anyone run into this or similar problems before ? Thoughts on
> > what's the right place to handle this issue ?
>
> run a dummy app at startup which reserves that port ?
Yes, I'm already aware of this one, but was looking for a lighter weight
solution (ideally a config file change) that doesn't involve running an
extra process (think of doing this on a large number of machines).
-Arun
commence Arun Sharma quotation:
> [email protected] (Xavier Bestel) writes:
>
>> Le sam 16/11/2002 ? 01:00, Arun Sharma a écrit? :
>> > One of the Intel server platforms has a magic port number (623) that
>> > it uses for remote server management. However, neither the kernel nor
>> > glibc are aware of this special port.
>> >
>> > As a result, when someone requests a privileged port using
>> > bindresvport(3), they may get this port back and bad things happen.
>> >
>> > Has anyone run into this or similar problems before ? Thoughts on
>> > what's the right place to handle this issue ?
>>
>> run a dummy app at startup which reserves that port ?
>
> Yes, I'm already aware of this one, but was looking for a lighter weight
> solution (ideally a config file change) that doesn't involve running an
> extra process (think of doing this on a large number of machines).
inetd
--
/ |
[|] Sean Neakums | Questions are a burden to others;
[|] <[email protected]> | answers a prison for oneself.
\ |
On 15 Nov 2002, Arun Sharma wrote:
| [email protected] (Xavier Bestel) writes:
|
| > Le sam 16/11/2002 ? 01:00, Arun Sharma a écrit? :
| > > One of the Intel server platforms has a magic port number (623) that
| > > it uses for remote server management. However, neither the kernel nor
| > > glibc are aware of this special port.
| > >
| > > As a result, when someone requests a privileged port using
| > > bindresvport(3), they may get this port back and bad things happen.
| > >
| > > Has anyone run into this or similar problems before ? Thoughts on
| > > what's the right place to handle this issue ?
| >
| > run a dummy app at startup which reserves that port ?
|
| Yes, I'm already aware of this one, but was looking for a lighter weight
| solution (ideally a config file change) that doesn't involve running an
| extra process (think of doing this on a large number of machines).
Look in arch/i386/kernel/setup.c (in 2.4.19):
There is this array:
struct resource standard_io_resources[] = ...
that you could add to; you could even make the addition a CONFIG_ option.
--
~Randy
"I read part of it all the way through." -- Samuel Goldwyn
[email protected] ("Randy.Dunlap") writes:
> Look in arch/i386/kernel/setup.c (in 2.4.19):
>
> There is this array:
> struct resource standard_io_resources[] = ...
> that you could add to; you could even make the addition a CONFIG_ option.
That's reserving I/O ports. Are you suggesting that we create an
analogous array for IP ports ?
-Arun
On 15 Nov 2002, Arun Sharma wrote:
| [email protected] ("Randy.Dunlap") writes:
|
| > Look in arch/i386/kernel/setup.c (in 2.4.19):
| >
| > There is this array:
| > struct resource standard_io_resources[] = ...
| > that you could add to; you could even make the addition a CONFIG_ option.
|
| That's reserving I/O ports. Are you suggesting that we create an
| analogous array for IP ports ?
Nope. Sorry, I read too much into "port". :(
or maybe too much port.
--
~Randy
"I read part of it all the way through." -- Samuel Goldwyn
On Sat, 2002-11-16 at 00:00, Arun Sharma wrote:
> One of the Intel server platforms has a magic port number (623) that
> it uses for remote server management. However, neither the kernel nor
> glibc are aware of this special port.
I can't find it in the IETF standards documents either.
> As a result, when someone requests a privileged port using
> bindresvport(3), they may get this port back and bad things happen.
They have at least as much right to it as you do
> Has anyone run into this or similar problems before ? Thoughts on
> what's the right place to handle this issue ?
Run your remote management daemon from xinetd, it'll then get the port
nice and early in the system runtime.
On Fri, Nov 15, 2002 at 04:00:37PM -0800, Arun Sharma wrote:
>
> One of the Intel server platforms has a magic port number (623) that
> it uses for remote server management. However, neither the kernel nor
> glibc are aware of this special port.
>
> As a result, when someone requests a privileged port using
> bindresvport(3), they may get this port back and bad things happen.
The problem is that you want bindresvport() to fail and your bind() to
succeed, but bindresvport() calls bind(), so there's no way to distinguish
them.
But if you're willing to modify a bit your app and the kernel, at least there
would be a method. You could find a way to mark some ports "RESERVED", so that
bind() fails on them unless the socket has been set to SO_REUSEPORT. It's
unlikely that a caller of bindresvport() would set this flag on its socket.
But when you know you want this port for your app, you could explicitly set it.
This concept could be extended to reserve unprivileged ports. Eg, we could
mark 1521, 3128, ... reserved, so that only proper apps could bind on them,
and more importantly, connect() wouldn't use them.
Cheers,
Willy
On Fri, Nov 15, 2002 at 04:00:37PM -0800, Arun Sharma wrote:
> One of the Intel server platforms has a magic port number (623) that
> it uses for remote server management. However, neither the kernel
> nor glibc are aware of this special port.
Odd.
charon:~% grep -c 623 /etc/services
0
rfc1700:
[...]
WELL KNOWN PORT NUMBERS
The Well Known Ports are controlled and assigned by the IANA and on
most systems can only be used by system (or root) processes or by
programs executed by privileged users.
[...]
npmp-gui 611/tcp npmp-gui
npmp-gui 611/udp npmp-gui
# John Barnes <[email protected]>
ginad 634/tcp ginad
ginad 634/udp ginad
I don't see port 623 in there. Where is this documented?
> As a result, when someone requests a privileged port using
> bindresvport(3), they may get this port back and bad things happen.
Indeed. It seems like they should be able to get this port.
What bad things happen?
> Has anyone run into this or similar problems before ? Thoughts on
> what's the right place to handle this issue ?
User-land. Fix broken applications.
--cw
Alan Cox <[email protected]> writes:
> On Sat, 2002-11-16 at 00:00, Arun Sharma wrote:
> > One of the Intel server platforms has a magic port number (623) that
> > it uses for remote server management. However, neither the kernel nor
> > glibc are aware of this special port.
>
> I can't find it in the IETF standards documents either.
It's been registered as a well known port:
http://www.iana.org/assignments/port-numbers
[..]
>
> > Has anyone run into this or similar problems before ? Thoughts on
> > what's the right place to handle this issue ?
>
> Run your remote management daemon from xinetd, it'll then get the port
> nice and early in the system runtime.
The thing that's unique about our situation is that the daemon in not
user level. It runs at hardware/firmware level, so that you can
remotely administer the machine even when software is malfunctioning.
-Arun
On Sun, 2002-11-17 at 16:37, Arun Sharma wrote:
> The thing that's unique about our situation is that the daemon in not
> user level. It runs at hardware/firmware level, so that you can
> remotely administer the machine even when software is malfunctioning.
So you've got an administration port that ignores the firewall
facilities on the machine. Now tell me why anyone would buy such a
product ? What if your firmware has a network layer bug, what if someone
finds a security hole in it ?
If you want to steal ports from under the OS then you need your own IP
address and full network stack, not the one assigned to the Linux
system.
Alan