I'm using apache2 together with fastcgi, suexec and php. To configure php I'm using a wrapper script to set PHPRC, which then exec's php itself.

I don't want users to set their own PHPRC, so they could modify the php.ini for their site. This means users shouldn't be able
to write to the wrapper script. The problem is that suexec requires the wrapper script to be owned by the user it should be executed as, which means
the user could modify this script.

The same problem occurs when you want to provide some cgi scripts for your users in a central location. Suexec requires them to be owned by the user
it should be executed as. Usually these shared cgi scripts are owned by root, or another account which is 'trusted'.

So the actual item for the wishlist is to be able to specify a user (or more than one) that are considered trusted. Suexec will then allow files
owned by either the target user, or by a trusted user, to be executed.

Alexander

Hi,

First of all, have you looked at

suphp
sbox-dtc
cgiwrap/php-cgiwrap

to see if any of them meet your needs? I don't know any of them but
maybe one of them already has the feature you need.

Second, you could use "chattr +i" to prevent users from changing the
wrapper. This is somewhat fragile, though, because backup programs
usually will not restore the immutable flag.

Apart from that, allowing scripts owned by root to be executed as any
user would certainly create (local) security issues. Using a
dedicated user might be possible, though.

But I intend to keep apache2-suexec-custom as close as possible to the
normal suexec and would prefer to not add any more features.

Cheers,
Stefan

Stefan Fritsch wrote:

Yes, I've looked at them. The problem is that libapache2-mod-fastcgi is
written in mind to be used together with suexec. The calling convention
usually is different for other programs like suphp.

I've tried that approach, and it is indeed fragile. Certainly when I
want the cgi script itself to be autogenerated by another script, which
takes into account user preferences etc.

Why would running a root-owned script as a local user create a security
issue?

I understand that. The patch is quite trivial though. Are there any
other options besides maintaining my local patch?

It's unfortunate I have to maintain this local patch. I know many people
have the same setup as me, and also have to patch suexec themselves.

Thanks,

Alexander

Use chattr +i <file>

Ondrej.

That much we had already figured out.

Alexander Prinsier wrote:

Currently I do
- chattr -i $file
- replace $file
- chattr +i $file
:-|

Fortunately though, one can still <Alias> stuff like PHP forum software
etc. in the users' domains in order to keep it in a central location, as
only the wrapper has the suexec limitations, but not what is called by
the wrapper.

As for the CGI scripts, you are right, keeping them in a central place
is not currently possible. :-(
What I/my control panel do is, there is a central location where these
scripts are stored, an the users' cgi-bins are updated from that
location. One however has to take precautions (e.g. in the form of cron
jobs) to update the users once the central repository gets updated.
This is a pity as otherwise the modfcgid/fastcgi+php variant works
pretty well and is pretty secure too.

Not so. But this would mean that in many setups, any user would be
allowed to execute any root-owned program under the document root
that has mode +x as any _other_ user (above uid 100). This is
something that no admin would expect. The restriction that suexec can
only be executed by apache can often be circumvented. E.g. if user
are allowed to create php scripts in ~/public_html.

For lenny there isn't. For the next release after lenny we can think
about it again.

If a user is allowed to create a php script that will be executed as
www-data, he can just go read everyone else's data (like a config.php
which includes passwords to databases etc), because everyone else's data
must be readable by www-data to get served by apache in this setup.

Because of that, I don't think there are many setups allowing script
execution as www-data, but yes, in such a case there is a side-effect
with my suggestion, that most admins would not suspect.

But I'm targeting another audience here :) One where www-data is a
privileged user (has read access to everyone's data), and script
execution is only allowed as the user itself using suexec.

To circumvent the issue totally, I could modify it so that if the cmd is
inside the docroot, then the owner of the cmd must be the target user.
If the cmd is inside a cgi-docroot, then the owner must be root. (It's
up to the admin to make these docroot's non overlapping :)).

Alexander

I have a patch prepared. Attached is what I got so far, and seems to be
working fine. (It's the modified .dpatch file, not a patch to a dpatch).

So now a third line in /etc/apache2/suexec/www-data is supported, being
a cgi_docroot. Scripts inside this cgi_docroot, and owned by root are
allowed to be executed by the target user.

I believe this addition will be very useful. On the other hand I
understand you want to stick to suexec as close as possible. You have to
realize though that many people patch suexec themselves because their
distro doesn't deliver something more usable. It's probably more secure
to have one widely used patched version inside the distro than having
many different locally patched versions.

Alexander

Alexander Prinsier wrote:

And this is the file...

I haven't looked at your patch yet, but here are some more arguments.

You are just considering pure web servers. On a machine that has a web
server running but is also used for other things, users' home
directories will contain many things that are not readable by the
user www-data. If you have some insecure cgi script that allows to
read arbitrary files, every local user would be able to read
~/.ssh/id_rsa of every other local user. This is not possible with
the current, tighter suexec.

It's rather easy to get such a setup:

aptitude install apache2 libapache2-mod-php5
a2enmod userdir

The default mod_php config allows it. Probably this should be changed.

Stefan

Stefan Fritsch wrote:

I wasn't just considering web servers. On a shell server, regular users
can't execute suexec (only www-data can). I'm only considering the case
where www-data is a trusted user (as in, regular users can't execute
things as www-data).

You're right though that if there's an insecure cgi, that allows to read
any file, then you've got a problem. Whether this cgi is in the users
docroot, or in the cgi_docroot I'm proposing, that doesn't matter.

Instead of having each user install their own modified copies of some
cgi, I prefer doing it myself in one central place.

Yeah I know. It's easy to setup, performant (no suexec overhead), but
horrible security wise.

Alexander

This limitation is trivial to bypass, see below.

That's not what I meant. What I meant is that mod_php in the default
configuration allows the following:

User1 creates a script in /home/user1/public_html/cat.php with
contents:

<?php
passthru("cd /bin; /usr/lib/apache2/suexec user2 user2
cat /home/user2/.ssh/id_rsa");

then does "curl http://localhost/~user1/cat.php" and user1 has
executed suexec as user www-data, and suexec would in turn execute
cat as user2.

This does not actually work _only_ because suexec checks the docroot
and the owner of the executed program. Therefore it would be foolish
to remove both these checks.

But even if you only remove the owner check, you are still trusting
that it is safe if one user can exec everything in your docroot as
any other user. I don't think this is a good idea.

Cheers,
Stefan

Stefan Fritsch wrote:

Well yeah, if you misconfigure your system, it's easy to bypass all
sorts of things :), like you illustrated below. (misconfigured because
you apparently allow the execution of any binary as any user).

I'm assuming nobody can execute as www-data. www-data is supposed to be
a trusted user.

I didn't really check the security impact when www-data isn't trusted,
but my first thought is that it's still OK then, as long as your docroot
is set correctly.

You can make www-data trusted by forcing all cgi's to be executed using
suexec. Yes I know the default setup is not like this.

How would suexec allow the execution of /bin/cat which is outside the
docroot?

In my patch the program to be executed needs to be either in the
docroot, owned by the target user/group, or it needs to be in the
cgi_docroot, owned by root/root. cgi_docroot would typically be
/usr/lib/cgi-bin. /bin/cat doesn't get through the checks (unless
misconfigured).

So if supposing you allow users to execute as www-data AND you got some
bad cgi in the cgi_docroot, only then you got a problem.

I'm not really removing a check. I'm only making the exception that a
cgi in /usr/lib/cgi-bin owned by root/root is good to be executed as any
target user.

I believe you have the exact same security impact by copying all cgi's
in /usr/lib/cgi-bin to the users's public_html directory. If the cgi's
you put in /usr/lib/cgi-bin are "safe", then my patch has no security
impact.

Thanks for taking the time to discuss this.

Alexander

Considering that the majority of all systems with mod_php is
misconfigured in this way, one should not ship a package that relies
on the system not having this configuration. Especially since nearly
no admins are aware of the implications of suexec for local security.

Yes, you remove one of the two main barriers against exploitation by
local users. This makes it much more likely that an programming error
results in exploitable security issues.

That's not correct. With your patch you can execute the programs as
any user (including system users). With the normal suexec you can
only execucte the programs as those users, where you copied them to
the public_html directory. This is equivalent to some whitelist that
has to be configured by the admin.

Maybe it would be an option to make the list/range of users
configurable that suexec will switch to, with no user allowed by
default. Or one could store that allowed user list in the xattrs of
every program in the suexec cgi dir.

Stefan Fritsch wrote:

Ok that's an issue... Could be resolved by disabling any new
functionality by default and putting a big fat warning on the screen
when trying to enable it.

Only if the user can execute as www-data, which I assumed was
impossible. Right?

Even then, suexec checks the uid/gid is above some minimum, ruling out
system users. That makes suexec resemble more a blacklist than a
whitelist. So you're right my equivalence above is not 100% correct. In
my use case though, the two would be equivalent (because I want to allow
any non-system user to execute the cgi using suexec).

That's a nice idea to store that in the xattrs of the cgi's. But that
list would have to include any user on the system, except the few system
users... It's not very convenient. And then you're assuming a user can
execute as www-data.

The min_uid and min_gid like suexec uses already is far more easy to
administer. But it gives you less flexibility as with the xattrs idea,
because then suexec uses a blacklist instead of a whitelist. Still, in
99% of the cases, people don't need such a whitelist.

I really think this cgi_docroot should only be used when users can't
execute as www-data, and the admin is fully documented about it's
impact. Discussing the impact when a user could execute as www-data is
interesting though.

Alexander

I know this is old, does it mean it won't change?

I wanted to do exactly the same than Alexander, this is in my opinion a
huge security feature.
Eg: i wanted to avoid the use of a wrapper and call directly php-cgi
with the right environment variable (i'm not even sure if it's
possible), + use the Trusted path execution security feature of
grsecurity to prevent all users from running any binary not root-owned.

This would prevent local users from modifying their wrapper script and
also help to add stronger security measures.

مرسل من هاتف Samsung Galaxy الذكي.

Laba diena,


Noriu Jus informuoti apie šių metų pasikeitimą dėl atnaujintos visos Lietuvos įmonių bazės 2018 metų sausio vidurio.
Visi juridiniai asmenys pateikti bazėje yra veikiantys, realiai vykdantys veiklą, turintys įdarbintų darbuotojų. Duomenys pagal Sodrą, Registrų centrą.

Bazėje nurodoma ir apyvarta, darbuotojų atlyginimai, darbuotojų skaičius, transporto skaičius ir daug kitų duomenų, kuriuos matysite pavyzdyje.

Duomenis galima filtruoti pagal veiklas, miestus ir kitus duomenis.


Šią bazę verta turėti visoms įmonėms. Pateiksiu priežastis:

1) Kontaktai pateikti bazėje direktorių ir kitų atsakingų asmenų, didelė tikimybė Jums surasti naujų klientų, partnerių, tiekėjų, kai tiesiogiai bendrausite su direktoriais, komercijos vadovais.

2) Konkurentų analizavimas, tiekėjų atsirinkimas pagal Jums reikalingus kriterijus, galite atsifiltruoti pagal įmonės dydį, bazėje nurodoma kiek įmonės skolingos Sodrai.

3) Lengva, greita ir patogu dirbti su šia baze, elektroninius pašto adresus galite importuoti į elektroninių laiškų siuntimo programas ar sistemas iš kurių siunčiate elektroninius laiškus.
Taip pat galite importuoti mobiliųjų telefonų numerius į SMS siuntimo programas.


Išsirinkite iš "Veiklų sąrašo" veiklas kurių Jums reikia.
( Sąrašas prisegtas laiške excel faile )

Parašykite, kurias veiklas išsirinkote
ir atsiųsime pavyzdį ir pasiūlymą su sąlygomis įmonių bazei įsigyti



Pagarbiai,
Tadas Giedraitis
Tel. nr. +37067881041

Hello,

Our partners referred your company to us. Regarding your great products.
Please see required products, quantity and specifications as attached.

Kindly give us your lowest possible prices for FCL shipment.


Best Regards,

Wanda Rodriguez
Purchase Assistant

Hidroconta Trading Ltd.
Av. de Sta. Catalina,
60, 30012 Murcia, Spain
Phone: +34 968 26 77 66
Fax: +34 968 26 77 06

Hello there,

I hope this message finds you in good spirits especially during
this challenging time of coronavirus pandemic. I hope you and
your family are well and keeping safe. Anyway, I am Chris
Pavlides, a broker working with Flippiebecker Wealth. I got your
contact (along with few other contacts) through an online
business directory and I thought I should contact you to see if
you are interested in this opportunity. I am contacting you
because one of my high profile clients is interested in investing
abroad and has asked me to look for individuals and companies
with interesting business ideas and projects that he can invest
in. He wants to invest a substantial amount of asset abroad.

Please kindly respond back to this email if you are interested in
this opportunity. Once I receive your response, I will give you
more details and we can plan a strategy that will be beneficial
to all parties.

Best regards

C Pavlides
Flippiebecker Wealth

Dzień dobry,

kontaktuję się z Państwem, ponieważ dostrzegam możliwość redukcji opłat za prąd.

Odpowiednio dobrana instalacja fotowoltaiczna to rozwiązanie, które pozwala wygenerować spore oszczędności w skali roku.

Chciałbym porozmawiać z Państwem o tego typu rozwiązaniu, a także przedstawić wstępne kalkulacje.

Czy są Państwo zainteresowani?

Pozdrawiam,
Dorian Kwiatkowski

Dzień dobry,

jakiś czas temu zgłosiła się do nas firma, której strona internetowa nie pozycjonowała się wysoko w wyszukiwarce Google.

Na podstawie wykonanego przez nas audytu SEO zoptymalizowaliśmy treści na stronie pod kątem wcześniej opracowanych słów kluczowych. Nasz wewnętrzny system codziennie analizuje prawidłowe działanie witryny.  Dzięki indywidualnej strategii, firma zdobywa coraz więcej Klientów.

Czy chcieliby Państwo zwiększyć liczbę osób odwiedzających stronę internetową firmy? Mógłbym przedstawić ofertę?


Pozdrawiam serdecznie,
Patryk Górecki

Dzień dobry!

Czy mógłbym przedstawić rozwiązanie, które umożliwia monitoring każdego auta w czasie rzeczywistym w tym jego pozycję, zużycie paliwa i przebieg?

Dodatkowo nasze narzędzie minimalizuje koszty utrzymania samochodów, skraca czas przejazdów, a także tworzenie planu tras czy dostaw.

Z naszej wiedzy i doświadczenia korzysta już ponad 49 tys. Klientów. Monitorujemy 809 000 pojazdów na całym świecie, co jest naszą najlepszą wizytówką.

Bardzo proszę o e-maila zwrotnego, jeśli moglibyśmy wspólnie omówić potencjał wykorzystania takiego rozwiązania w Państwa firmie.


Z poważaniem,
Dawid Rowicki

Dzień dobry!

Czy mógłbym przedstawić rozwiązanie, które umożliwia monitoring każdego auta w czasie rzeczywistym w tym jego pozycję, zużycie paliwa i przebieg?

Dodatkowo nasze narzędzie minimalizuje koszty utrzymania samochodów, skraca czas przejazdów, a także tworzenie planu tras czy dostaw.

Z naszej wiedzy i doświadczenia korzysta już ponad 49 tys. Klientów. Monitorujemy 809 000 pojazdów na całym świecie, co jest naszą najlepszą wizytówką.

Bardzo proszę o e-maila zwrotnego, jeśli moglibyśmy wspólnie omówić potencjał wykorzystania takiego rozwiązania w Państwa firmie.


Z poważaniem,
Dawid Rowicki

Dzień dobry,

czy interesuje Państwa wymiana niezapłaconych przez Klientów faktur na gotówkę?

Pomagamy wszystkim przedsiębiorcom, którzy szukają gwarancji bezpieczeństwa i płynności finansowej.

Jeśli są Państwo otwarci na wstępną rozmowę w tym temacie proszę o odpowiedź.


Pozdrawiam,
Adrian Ostojski
Dyrektor Finansowy