I just opened a discussion on the upstream util-linux list:
http://marc.info/?t=14569474891=1=2
Discussion there proposes to fix it in the kernel:
Disallow the use of TIOCSTI to unprivileged users unless the caller has
CAP_SYS_ADMIN.
--
Best Regards / S pozdravem,
Stanislav Brabec
On 2/29/2016 1:29 PM, up201407...@alunos.dcc.fc.up.pt wrote:
> He said looking into it, he didn't find any legitimate uses of such ioctl.
That was the other thing I was wondering about: why would such a silly
and security problematic ioctl exist in the first place? I guess that
answers it, and
Quoting "Phil Susi" :
On 2/27/2016 4:23 AM, up201407...@alunos.dcc.fc.up.pt wrote:
And yes, there would be no job control if you started a shell from
there. This is why in "su" setsid() is called only with "-c", partially
fixing the issue. If one would to "su - user" it would
On 2/27/2016 4:23 AM, up201407...@alunos.dcc.fc.up.pt wrote:
> And yes, there would be no job control if you started a shell from
> there. This is why in "su" setsid() is called only with "-c", partially
> fixing the issue. If one would to "su - user" it would still be vulnerable.
That isn't
Quoting "Phil Susi" :
How does setsid() help this? And wouldn't it break the ability to use
ctrl-c and ctrl-z on the child program ( since the child won't have a
controlling terminal )? I would think the fix would be to simply flush
the terminal input buffer after the child
On 2/25/2016 1:51 PM, up201407...@alunos.dcc.fc.up.pt wrote:
> When executing a program via "runuser -u nonpriv program" the
> nonpriv session can
> escape to the parent session by using the TIOCSTI ioctl to push
> characters into the
> terminal's input buffer, allowing privilege escalation.
>
Package: util-linux
Version: all
Severity: important
When executing a program via "runuser -u nonpriv program" the
nonpriv session can
escape to the parent session by using the TIOCSTI ioctl to push
characters into the
terminal's input buffer, allowing privilege escalation.
This issue has been
7 matches
Mail list logo