PTY DOS vulnerability?

PTY DOS vulnerability?

[Fredrik Tolf]

Has someone considered PTYs as a possible attack vector for DOS 
attacks? Correct me if I'm wrong, but cannot someone just open 
all available PTYs on a console-less server and make everyone 
unable to log in?

I mean, what if eg. apache is hacked, and the first thing the 
attacker does is to tie up all PTYs, so that noone can log in to 
correct the situation while the attacker can go about his 
business? Then the only possible solution would be to reboot the 
server, which might very well not be desirable.

If you want proof of concept code, look at
http://www.dolda2000.cjb.net/~fredrik/ptmx.c
I successfully ran this on one of my servers which effectively 
disabled anyone from logging in via SSH.

Shouldn't PTYs be a per-user resource limit?

Someone must have thought of this before me, right? How am I 
wrong?

Fredrik Tolf

Re: PTY DOS vulnerability?

[Alan Cox]

On Llu, 2003-06-30 at 15:18, Fredrik Tolf wrote:
> Shouldn't PTYs be a per-user resource limit?

It depends to what degree you consider your users hostile. But yes its
possibly one of the things to do per user counting on.

Re: PTY DOS vulnerability?

[Fredrik Tolf]

I'll summarize some of the answers:

On Monday 30 June 2003 19:55, Alan Cox wrote:
> On Llu, 2003-06-30 at 15:18, Fredrik Tolf wrote:
> > Shouldn't PTYs be a per-user resource limit?
>
> It depends to what degree you consider your users hostile. But
> yes its possibly one of the things to do per user counting on.

It isn't necessarily an entitled user; see below. But even if it 
is, I think it should be able to limit it, just as it is 
possible to put a limit on processes.

On Monday 30 June 2003 17:52, Marcelo Bezerra wrote:
> On Mon, 2003-06-30 at 11:18, Fredrik Tolf wrote:
> > Shouldn't PTYs be a per-user resource limit?
>
> This would help, but not solve.
>
> Once he roots your box, he can easly change the script to
> setuid each uid possible and request all ptys it can.
>
> Or he could run it as root, without the limit.

That is provided that he is able to root the system. Take for 
example Apache, a program that is relatively often cracked. It, 
as many other programs, doesn't run as root. If the attacker 
could tie up all PTYs, though, he could go on his business 
(extracting confidential information, subnet scanning, etc.) 
without root being able to log in to stop him. Instead, the 
admimistrator might have to call the datacenter to get them to 
reboot the box.
Of course, if the attacker is able to root the box, it doesn't 
help very with a resource limit, but that's more of an issue for 
the grsecurity project, isn't it?

On Monday 30 June 2003 16:24, Mark Hahn wrote:
> pty's are not required for ssh activity, though they would
> make it tricker.

That is true, though, of course. Stupid me not to think about 
that. However, that means that an administrator who could find 
himself being under such an attack might not think about it 
either. Also, from the outside, the ssh client just does 
nothing, making it look as if the server is unresponsive. Of 
course, the exact error is logged to the server's syslog, but if 
you can't view it, then you won't know about it.

So all in all, do you think I should implement a per-user 
resource limit on PTYs?

Fredrik Tolf

Re: PTY DOS vulnerability?

[Alan Cox]

On Llu, 2003-06-30 at 22:31, Fredrik Tolf wrote:
> That is true, though, of course. Stupid me not to think about 
> that. However, that means that an administrator who could find 
> himself being under such an attack might not think about it 
> either. Also, from the outside, the ssh client just does 
> nothing, making it look as if the server is unresponsive. Of 
> course, the exact error is logged to the server's syslog, but if 
> you can't view it, then you won't know about it.
> 
> So all in all, do you think I should implement a per-user 
> resource limit on PTYs?

There are a whole collection of things that would benefit from that kind
of management - go for it but make it possible to add other stuff too

Re: PTY DOS vulnerability?

[Oleg Drokin]

Hello!

On Mon, Jun 30, 2003 at 04:18:36PM +0200, Fredrik Tolf wrote:
> Has someone considered PTYs as a possible attack vector for DOS 
> attacks? Correct me if I'm wrong, but cannot someone just open 
> all available PTYs on a console-less server and make everyone 
> unable to log in?

ability to login != availability of free ptys.

> I mean, what if eg. apache is hacked, and the first thing the 
> attacker does is to tie up all PTYs, so that noone can log in to 
> correct the situation while the attacker can go about his 
> business? Then the only possible solution would be to reboot the 
> server, which might very well not be desirable.

Nope.
slogin someuser@someserver "/bin/bash -i"
will let you in even if you do not have a single pty free. Try it.
If course job control won't work and other minor things are there,
but still this is enough to e.g kill apache and all of its children in your case.

> Shouldn't PTYs be a per-user resource limit?

This one is still interesting, though.

Bye,
    Oleg

Re: PTY DOS vulnerability?

[Jesse Pollard]

On Monday 30 June 2003 09:18, Fredrik Tolf wrote:
> Has someone considered PTYs as a possible attack vector for DOS
> attacks? Correct me if I'm wrong, but cannot someone just open
> all available PTYs on a console-less server and make everyone
> unable to log in?
>
> I mean, what if eg. apache is hacked, and the first thing the
> attacker does is to tie up all PTYs, so that noone can log in to
> correct the situation while the attacker can go about his
> business? Then the only possible solution would be to reboot the
> server, which might very well not be desirable.
>
> If you want proof of concept code, look at
> http://www.dolda2000.cjb.net/~fredrik/ptmx.c
> I successfully ran this on one of my servers which effectively
> disabled anyone from logging in via SSH.
>
> Shouldn't PTYs be a per-user resource limit?
>
> Someone must have thought of this before me, right? How am I
> wrong?

One problem is that ptys are not just "used by the user". Every terminal
window opened uses a pty. As does a network connection.

As does "expect" - which is less visible to the user since it is intended
to be invisible.

The real question is "how many PTYs should a single user have?"
Which then prompts the question "How many concurrent users should there be?"

second, just providing a user limit doesn't prevent a denial of service..
Just have more connections than ptys and you are in the same situation.

Re: PTY DOS vulnerability?

[Jesse Pollard]

On Monday 30 June 2003 16:36, Alan Cox wrote:
> On Llu, 2003-06-30 at 22:31, Fredrik Tolf wrote:
> > That is true, though, of course. Stupid me not to think about
> > that. However, that means that an administrator who could find
> > himself being under such an attack might not think about it
> > either. Also, from the outside, the ssh client just does
> > nothing, making it look as if the server is unresponsive. Of
> > course, the exact error is logged to the server's syslog, but if
> > you can't view it, then you won't know about it.
> >
> > So all in all, do you think I should implement a per-user
> > resource limit on PTYs?
>
> There are a whole collection of things that would benefit from that kind
> of management - go for it but make it possible to add other stuff too

In thinking about that...

I would suggest a "resource allocation daemon", where resource is defined
to be non-kernel objects - devices mostly... ptys /dev/tape unmounted disks
removable media, specific files (not sure how to explain this one though, but
controlling access to specified fifo's, memory mapped files? how about 
printer queues...)

Anything that gets defined as a system wide resource that users may access, 
but exist as external (to the kernel) objects. It would need some kind of 
kernel interface, but the access control would be defined outside the kernel.

The most the kernel would need is a "resource controlled by" and "resource 
allocated to" identification so that the appropriate daemon could be invoked
(I do see a possibility for multiple resource allocation daemons).

Re: PTY DOS vulnerability?

[Timothy Miller]

How about giving each user his own set of virtual ptys?

Alan Cox wrote:
> On Llu, 2003-06-30 at 22:31, Fredrik Tolf wrote:
> 
>>That is true, though, of course. Stupid me not to think about 
>>that. However, that means that an administrator who could find 
>>himself being under such an attack might not think about it 
>>either. Also, from the outside, the ssh client just does 
>>nothing, making it look as if the server is unresponsive. Of 
>>course, the exact error is logged to the server's syslog, but if 
>>you can't view it, then you won't know about it.
>>
>>So all in all, do you think I should implement a per-user 
>>resource limit on PTYs?
> 
> 
> There are a whole collection of things that would benefit from that kind
> of management - go for it but make it possible to add other stuff too
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
> 

Re: PTY DOS vulnerability?

[Helge Hafting]

On Tue, Jul 01, 2003 at 06:57:49AM -0500, Jesse Pollard wrote:
> 
> One problem is that ptys are not just "used by the user". Every terminal
> window opened uses a pty. As does a network connection.
> 
> As does "expect" - which is less visible to the user since it is intended
> to be invisible.
> 
> The real question is "how many PTYs should a single user have?"
> Which then prompts the question "How many concurrent users should there be?"
> 
> second, just providing a user limit doesn't prevent a denial of service..
> Just have more connections than ptys and you are in the same situation.

Isn't this something a improved sshd could do?  I.e. if the
connection using up the last (or one of the last) pty's logs
in as non-root - just kill it.

Re: PTY DOS vulnerability?

[Paul Rolland]

Hello,

> > second, just providing a user limit doesn't prevent a denial of 
> > service.. Just have more connections than ptys and you are 
> in the same 
> > situation.
> 
> Isn't this something a improved sshd could do?  I.e. if the 
> connection using up the last (or one of the last) pty's logs 
> in as non-root - just kill it.

Why restricting this to SSH ? I mean, this can occur even if you
are not using SSH.

Some per-user limit seems to be good... but if we do that, what about
also limiting the number of TCP/UDP ports used on a per-user basis ?

In fact, all the resources that are available should be per-user limited
if you want to avoid a single one causing a complete DoS...
 - CPU
 - Memory
 - Network
 - Disk
 - Pty
 - ...

Paul

Re: PTY DOS vulnerability?

[Jesse Pollard]

On Tuesday 01 July 2003 14:53, Helge Hafting wrote:
> On Tue, Jul 01, 2003 at 06:57:49AM -0500, Jesse Pollard wrote:
> > One problem is that ptys are not just "used by the user". Every terminal
> > window opened uses a pty. As does a network connection.
> >
> > As does "expect" - which is less visible to the user since it is intended
> > to be invisible.
> >
> > The real question is "how many PTYs should a single user have?"
> > Which then prompts the question "How many concurrent users should there
> > be?"
> >
> > second, just providing a user limit doesn't prevent a denial of service..
> > Just have more connections than ptys and you are in the same situation.
>
> Isn't this something a improved sshd could do?  I.e. if the
> connection using up the last (or one of the last) pty's logs
> in as non-root - just kill it.

and how is it to determine that it is the last?

try two and die if the second fails???

at least one system just creates more ptys...

Re: PTY DOS vulnerability?

[H. Peter Anvin]

Followup to:  <03070220143600.04348@tabby>
By author:    Jesse Pollard <jesse@cats-chateau.net>
In newsgroup: linux.dev.kernel
> >
> > Isn't this something a improved sshd could do?  I.e. if the
> > connection using up the last (or one of the last) pty's logs
> > in as non-root - just kill it.
> 
> and how is it to determine that it is the last?
> try two and die if the second fails???
> at least one system just creates more ptys...
> 

Viro's working on it... but as someone else pointed out,
"ssh root@machine bash -i" works great without any ptys.  You don't
have all features, but enough to nuke whatever it is that's eating
them all.

     -hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64

Re: PTY DOS vulnerability?

[Svein Ove Aas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

onsdag 9. juli 2003, 01:11, skrev Clayton Weaver:
> Seems to me that a pty ulimit and making
> sure that root can always access an unused
> pty on demand are separate issues.
>
> The ulimit is the same issue that it is for
> open files, disk quota, aggregate per-user
> memory utilization, etc, maintaining the
> "multi-user" aspect of system usability.
>
> Making sure that root has the tools to do
> what is needed in a pty resource exhaustion
> situation deserves perhaps a different
> mechanism, like dynamic, on-demand pty device
> creation for root (which seems to me more
> robust than a "reserved for root" mechanism,
> which allows the possibility that root
> processes have already used up that many
> ptys when root needs one in an emergency).

But if you're going to do that for root, then why not do it for all users?
That would avoid the problem altogether, after all...

- - Svein Ove Aas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/C+mH9OlFkai3rMARAvlIAKCuBSdCx31kgcMP8hFaEx3qkdWiZwCfUI0A
YSDkrEFpFnmIkzXUi1E7Tnw=
=Hmkz
-----END PGP SIGNATURE-----

Re: PTY DOS vulnerability?

[Clayton Weaver]

Seems to me that a pty ulimit and making
sure that root can always access an unused
pty on demand are separate issues.

The ulimit is the same issue that it is for
open files, disk quota, aggregate per-user
memory utilization, etc, maintaining the
"multi-user" aspect of system usability.

Making sure that root has the tools to do
what is needed in a pty resource exhaustion
situation deserves perhaps a different
mechanism, like dynamic, on-demand pty device
creation for root (which seems to me more
robust than a "reserved for root" mechanism,
which allows the possibility that root
processes have already used up that many
ptys when root needs one in an emergency).

Regards,

Clayton Weaver
<mailto: cgweav@email.com>

PS: Linux Golf Howto addenda

Long grass: when hitting out of long grass,
the grass tends to wrap around the heel of the club, where the club face meets the club shaft,
without offering comparable resistance to the
toe of the club face. This tends to close the
club face and deliver it to the ball at not
quite the intended angle. Solution: tilt the
toe of the club away from the ball a few
degrees before gripping the club. Soft,
well-watered green grass a few inches long
needs less opening of the club face than
foot long dry grass (more fiber in stems
than leaves) to accomplish the necessary
adjustment.

-- 
__________________________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup

CareerBuilder.com has over 400,000 jobs. Be smarter about your job search
http://corp.mail.com/careers