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

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

/home/loser is with permissions 755, default umask 0022

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

Contents

  /home/loser is with permissions 755, default umask 0022 Georgi Guninski <gguninski@gmail.com> - 2020-10-07 12:40 +0200
    Re: /home/loser is with permissions 755, default umask 0022 Giacomo Catenazzi <cate@debian.org> - 2020-10-07 14:50 +0200
      Re: /home/loser is with permissions 755, default umask 0022 Georgi Guninski <gguninski@gmail.com> - 2020-11-13 08:20 +0100
        Re: /home/loser is with permissions 755, default umask 0022 Richard van den Berg <richard@vdberg.org> - 2020-11-13 09:30 +0100
        Re: /home/loser is with permissions 755, default umask 0022 Bjørn Mork <bjorn@mork.no> - 2020-11-13 09:40 +0100

#5853 — /home/loser is with permissions 755, default umask 0022

/home/loser is with permissions 755, default umask 0022

on multiuser machines this sucks much.

on a multiuser debian mirror we found a lot of data,
including the wordpress password of the admin.

[toc] | [next] | [standalone]

#5854

On 07.10.2020 12:39, Georgi Guninski wrote:
> /home/loser is with permissions 755, default umask 0022
> 
> on multiuser machines this sucks much.
> 
> on a multiuser debian mirror we found a lot of data,
> including the wordpress password of the admin.

Welcome to user webpage nightmare.

How would you solve it?

Webserver requires to have access to Wordpress admin password, so either 
such file is readable by external users (group doesn't work, because all 
users are in the same groups), or you give all your users a permission 
to set the webfiles as server group (but because all users have this, it 
may be easy to break the walls).

You may be smarter with group and permissions, but it is very tricky. Or 
a random generated URL, e.g. (www-xbjX72naFl832bYz332 [this is not 
random, just an idea])

So there is not easy way. There is/was suphp, which execute the PHP code 
as the user, so you can remove the "Other can read" permission, or just 
as common for other languages: setup a proxy, so your code is executed 
only by you, and you send the result to webserver (but this is also 
tricky, if you have non-trusted users: one may crash your server, or 
just wait the restart, and take over the port. [Note: you can filter 
owner with firewall]).

So as you see, this is tricky and error prone. Now it is better to use 
virtual machines. But i can confirm that many sites are handled wrongly 
("it is just for few personal webpages", then they added shop, company 
sites, etc.).

So you found an error on a machine: tell the administrator to solve it.


But you listed an other problem: a debian mirror with a lot of user 
data, and wordpress.

If it is an official Debian mirror, you may need to contact our DSA, so 
that they will contact mirror administrator and help to configure the 
mirror properly. We do not run PHP or any other language, on our 
mirrors, so our mirror files should be fine, but an insecure official 
server is still a problem.

ciao
	cate

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

#5878

Some more exploit vectors from the FD list:
https://seclists.org/fulldisclosure/2020/Nov/13

Partial results:

1. mutt (text email client) exposes ~/.mutt/muttrc,
which might contain the imap password in plaintext.

2. Some time ago on a multiuser debian mirror we found a lot of data,
including the wordpress password of the admin.

3. Anything created by EDITOR NEWFILE is readable, unless the directory
prevents. This include root doing EDITOR /etc/NEWFILE

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

#5882

On 13-11-2020 08:18, Georgi Guninski wrote:
> Some more exploit vectors from the FD list:
> https://seclists.org/fulldisclosure/2020/Nov/13
>
> Partial results:
>
> 1. mutt (text email client) exposes ~/.mutt/muttrc,
> which might contain the imap password in plaintext.

Interesting find. Please report this to the mutt package maintainer 
using reportbug[1].


> 2. Some time ago on a multiuser debian mirror we found a lot of data,
> including the wordpress password of the admin.

As Giacomo already explained, there is nothing an OS can do to stop the 
insecure behavior of its users.


> 3. Anything created by EDITOR NEWFILE is readable, unless the directory
> prevents. This include root doing EDITOR /etc/NEWFILE

Yes, that is indeed the default. If you don't like it, you can change 
the system umask in /etc/login.defs or /etc/profile

Somehow I get the feeling you are using debian-security@lists.debian.org 
to report a security issues with Debian. This is however just a 
discussion mailing list about Debian security. If you wish to report a 
serious security issue (which I did not find in your E-mails) you need 
to contact the Debian Security Team[2].

Kind regards,

Richard

[1]: https://wiki.debian.org/reportbug
[2]: https://www.debian.org/security/faq#contact

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

#5884

Your question(?) is answered by the FAQ in
https://www.debian.org/doc/manuals/securing-debian-manual/index.en.html


Bjørn

[toc] | [prev] | [standalone]

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

csiph-web