~alpine/devel

1

Re: Security problem in how you manage users in package installations

Details
Message ID
<68F5D483-C814-476D-A460-BC1C29D402BF@tower-net.de>
DKIM signature
missing
Download raw message
Am 21. Juni 2022 18:18:39 UTC schrieb Ariadne Conill <ariadne@dereferenced.org>:
>Hi,
>
>On Tue, 21 Jun 2022, Markus Kolb wrote:
>
>> Am 19.06.2022 19:23, schrieb Jakub Jirutka:
>>>> There is the possibility to allow an unintended (remote) login or local privilege expansion by unlocking users in apk-executed scripts.
>>> 
>>> No, if the user already exists, then adduser(8) does nothing.
>>> 
>> 
>> But passwd does. Unlocking is happening with passwd and not adduser.
>
>In the case of Gogs and Gitea, this is necessary to enable the package to work as intended.  The user accounts are restricted to running the Gogs / Gitea shell helper and cannot by default run a normal /bin/sh.
>
>> Not sure why you all point to adduser?!
>
>The typical pattern is to use adduser to add users in post-install scripts, this is admittedly sub-optimal design but requires the package manager to be aware of what account mutations need to occur.
>
>> Can you all try to understand the problem and not try to avoid the explanations and saying all is fine like it is?!
>
>Speaking with authority as Alpine's designated security officer, I do not see the problem with the Gogs / Gitea packages.
>
>> It is not, you have a package in your repository, where you can get for sure a CVE entry for because of how it is installed by apk.
>
>Speaking with authority as Alpine's designated security officer, we will vehemently dispute any CVE entries filed for this issue.
>
>> This is all quite exhausting to discuss a problem like there is no problem and need to explain things not being part of.
>
>Speaking with authority as Alpine's designated security officer, multiple members of the Alpine security team have explicitly told you that we do not believe there is a problem in this case.
>
>The Alpine security team does, however, believe that `passwd -u` should be avoided as a best practice unless it is justifiable.  In this case, it is justifiable -- the accounts in question must be unlocked for the package to function as intended.
>
>> This is no help.
>
>Demanding we do what you want is also not helpful.  If you believe this is a real problem, then show us a real exploit.  At present, all I am seeing is that a user must:
>
>1. Add a `gogs` or `gitea` account to their system.
>2. Lock that account.
>3. Install `gogs` or `gitea` which results in it being unlocked.
>
>If you go to a doctor and say "it hurts when I do this," the doctor will tell you "don't do that."  Same principle here.
>
>Ariadne

Ups, put this by accident also on user list during an answer. The start has been on devel list. But now it's also on user.

Seems, you are not qualified, Ariadne, or is my English too bad? 
There is no need for an exploit.

1. Install gogs and openssh-server.
2. Start it
3. Create a login in gogs.
4. Create a private repository
5. Commit your most expensive code to your private repository
6. Create a normal ssh user account, fully unrelated to gogs
7. Give me access to this ssh user account
8. I'll tell you what your username, email and password hash in gogs is; complete DB dump possible
9. I'll sell your private repository code in dark net
10. You look for a new job

Sorry, you requested this.

You have my email, if you have prepared this quite common server and can't understand it yourself.
Anything more is waste of time for me, I have to replace my container images. Seem to be sleeping time bombs.
My intention has been to help and support you. Repair this permission problems in an official accepted way, while taking care of two unmaintained community packages. And talk about what could be done to make this safer in the development process, that packages are not distributed in such an unsafe state.
Mostly I receive over many days disbelief and now this laughable, insulting official statement.
Bye bye

Re: Security problem in how you manage users in package installations

Details
Message ID
<20220622121124.47484924@ncopa-desktop.lan>
In-Reply-To
<68F5D483-C814-476D-A460-BC1C29D402BF@tower-net.de> (view parent)
DKIM signature
missing
Download raw message
On Wed, 22 Jun 2022 03:06:41 +0000
Markus Kolb <alpinelinux+develml@tower-net.de> wrote:

> Am 21. Juni 2022 18:18:39 UTC schrieb Ariadne Conill <ariadne@dereferenced.org>:
> >Hi,
> >
> >On Tue, 21 Jun 2022, Markus Kolb wrote:
> >  
> >> Am 19.06.2022 19:23, schrieb Jakub Jirutka:  
> >>>> There is the possibility to allow an unintended (remote) login
> >>>> or local privilege expansion by unlocking users in apk-executed
> >>>> scripts.  
...

> 1. Install gogs and openssh-server.
> 2. Start it
> 3. Create a login in gogs.
> 4. Create a private repository
> 5. Commit your most expensive code to your private repository
> 6. Create a normal ssh user account, fully unrelated to gogs
> 7. Give me access to this ssh user account
> 8. I'll tell you what your username, email and password hash in gogs is; complete DB dump possible
> 9. I'll sell your private repository code in dark net
> 10. You look for a new job

This does not sound good at all, and I am interested in fixing it.

> 
> Sorry, you requested this.
> 
> You have my email, if you have prepared this quite common server and
> can't understand it yourself. Anything more is waste of time for me,
> I have to replace my container images. Seem to be sleeping time
> bombs.

But is this not just a problem that gogs package sets wrong permissions
to its database?

I don't understand how this is a general problem in apk executed
scripts?

> My intention has been to help and support you. Repair this
> permission problems in an official accepted way, while taking care of
> two unmaintained community packages. And talk about what could be
> done to make this safer in the development process, that packages are
> not distributed in such an unsafe state. Mostly I receive over many
> days disbelief and now this laughable, insulting official statement.

I am sorry.

-nc
Reply to thread Export thread (mbox)