Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.security > #5489 > unrolled thread

Which one is better solution?

Back to article view | Back to linux.debian.security

Contents

  Which one is better solution? JungHwan Kang <ultractgm@gmail.com> - 2018-12-15 12:20 +0100
    Re: Which one is better solution? Shea Alterio <krusete@gmail.com> - 2018-12-15 12:30 +0100
      Re: Which one is better solution? Ruslanas Gžibovskis <ruslanas@lpic.lt> - 2018-12-15 17:30 +0100
        Re: Which one is better solution? Cindy-Sue Causey <butterflybytes@gmail.com> - 2018-12-15 22:30 +0100
        Re: Which one is better solution? Elmar Stellnberger <estellnb@gmail.com> - 2018-12-16 09:00 +0100
          u+S  WAS: Which one is better solution? Geert Stappers <stappers@stappers.nl> - 2018-12-16 10:20 +0100

#5489 — Which one is better solution?

Sometimes, I use a sudo command with -s options for keeping
environment variables for users account(sudoer). I also know -s option
runs the shell specified by the SHELL environment variable. But the
SHELL environment variable can be manipulated by other users having
the same privilege.

So, I think an adversary is able to abuse the changing SHELL
environment variable for privilege escalation like a video below. (I
assume the adversary owned the permission for executing a shell on a
remote)

https://youtu.be/JSQjIm7377o (unlisted state)

I know it is uncertain when the sudo is executed with -s option by sudoer.

Anyway, I have thought of the solutions to the issue below.
 - using a pkexec of a Policy kit,
 - disable a ptrace function via kernel.yama.ptrace_scope, CAP_SYS_PTRACE.

Could you give some advice and comments?

Thx.

[toc] | [next] | [standalone]

#5490

[Multipart message — attachments visible in raw view] — view raw

As far as I know, pkexec doesn't validate arguments, so it might not be
ideal if you are worried about people trying to trick it.

On Sat, Dec 15, 2018 at 6:15 AM JungHwan Kang <ultractgm@gmail.com> wrote:

> Sometimes, I use a sudo command with -s options for keeping
> environment variables for users account(sudoer). I also know -s option
> runs the shell specified by the SHELL environment variable. But the
> SHELL environment variable can be manipulated by other users having
> the same privilege.
>
> So, I think an adversary is able to abuse the changing SHELL
> environment variable for privilege escalation like a video below. (I
> assume the adversary owned the permission for executing a shell on a
> remote)
>
> https://youtu.be/JSQjIm7377o (unlisted state)
>
> I know it is uncertain when the sudo is executed with -s option by sudoer.
>
> Anyway, I have thought of the solutions to the issue below.
>  - using a pkexec of a Policy kit,
>  - disable a ptrace function via kernel.yama.ptrace_scope, CAP_SYS_PTRACE.
>
> Could you give some advice and comments?
>
> Thx.
>
>

[toc] | [prev] | [next] | [standalone]

#5491

[Multipart message — attachments visible in raw view] — view raw

I prefer su or u+S on a script

On Sat, 15 Dec 2018, 12:29 Shea Alterio <krusete@gmail.com wrote:

> As far as I know, pkexec doesn't validate arguments, so it might not be
> ideal if you are worried about people trying to trick it.
>
> On Sat, Dec 15, 2018 at 6:15 AM JungHwan Kang <ultractgm@gmail.com> wrote:
>
>> Sometimes, I use a sudo command with -s options for keeping
>> environment variables for users account(sudoer). I also know -s option
>> runs the shell specified by the SHELL environment variable. But the
>> SHELL environment variable can be manipulated by other users having
>> the same privilege.
>>
>> So, I think an adversary is able to abuse the changing SHELL
>> environment variable for privilege escalation like a video below. (I
>> assume the adversary owned the permission for executing a shell on a
>> remote)
>>
>> https://youtu.be/JSQjIm7377o (unlisted state)
>>
>> I know it is uncertain when the sudo is executed with -s option by sudoer.
>>
>> Anyway, I have thought of the solutions to the issue below.
>>  - using a pkexec of a Policy kit,
>>  - disable a ptrace function via kernel.yama.ptrace_scope, CAP_SYS_PTRACE.
>>
>> Could you give some advice and comments?
>>
>> Thx.
>>
>>

[toc] | [prev] | [next] | [standalone]

#5493

On 12/15/18, Ruslanas Gžibovskis <ruslanas@lpic.lt> wrote:
> On Sat, 15 Dec 2018, 12:29 Shea Alterio <krusete@gmail.com wrote:
>
>> As far as I know, pkexec doesn't validate arguments, so it might not be
>> ideal if you are worried about people trying to trick it.
>>
>> On Sat, Dec 15, 2018 at 6:15 AM JungHwan Kang <ultractgm@gmail.com>
>> wrote:
>>
>>> Sometimes, I use a sudo command with -s options for keeping
>>> environment variables for users account(sudoer). I also know -s option
>>> runs the shell specified by the SHELL environment variable. But the
>>> SHELL environment variable can be manipulated by other users having
>>> the same privilege.
>>>
>>> So, I think an adversary is able to abuse the changing SHELL
>>> environment variable for privilege escalation like a video below. (I
>>> assume the adversary owned the permission for executing a shell on a
>>> remote)
>>>
>>> https://youtu.be/JSQjIm7377o (unlisted state)
>>>
>>> I know it is uncertain when the sudo is executed with -s option by
>>> sudoer.
>>>
>>> Anyway, I have thought of the solutions to the issue below.
>>>  - using a pkexec of a Policy kit,
>>>  - disable a ptrace function via kernel.yama.ptrace_scope,
>>> CAP_SYS_PTRACE.
>>>
>>> Could you give some advice and comments?
>>>
> I prefer su or u+S on a script


I've read the above responses and am not quite sure how this fits in
but decided to post anyway. :)

I started using "su" myself in last year or so. A blip that quickly
left my memory was that I'd seen a hyphen ("-") used at some point but
didn't understand the importance of adding the hyphen as needed
BECAUSE "su" appeared to work just fine WITHOUT the hyphen. :)

A few weeks ago, that very helpful topic came up on Debian-User, but
now I can't find that reference. Via Super User/StackExchange [0], I
*did* find:

"Of noteworthyness: This is particularly useful when su-ing to root as
without using the hypen to start a new login shell, your $PATH won't
get updated and thus you won't be able to directly call root-only
binaries in /sbin and /usr/sbin "

That important detail about fits what was shared on Debian-User
recently. Am additionally posting because it's not something newcomers
(and even old timers) to that concept encounter very readily out there
in the wild. :)

Cindy :)

[0] https://superuser.com/questions/453988/whats-the-difference-between-su-with-and-without-hyphen

-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs with birdseed *

[toc] | [prev] | [next] | [standalone]

#5494

what is u+S?

On 15.12.18 17:24, Ruslanas Gžibovskis wrote:
> u+S on a scr

[toc] | [prev] | [next] | [standalone]

#5495 — u+S WAS: Which one is better solution?

On Sun, Dec 16, 2018 at 08:54:05AM +0100, Elmar Stellnberger wrote:
> On 15.12.18 17:24, Ruslanas G??ibovskis wrote:
> > u+S on a scr
> 
> what is u+S?
 
Probably 'u+S' as in `chmod u+S scr`

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.security

csiph-web