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
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.
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
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
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
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.
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).
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
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.
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
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...
Followup to: <03070220143600.04348@tabby>
By author: Jesse Pollard <[email protected]>
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
--
<[email protected]> at work, <[email protected]> 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
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: [email protected]>
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
-----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-----