[SAC] Re: Subject: [Technical Problem] can't register on trac

Committees SAC mailing list
1

On Mon, Apr 09, 2012 at 05:25:35PM -0700, Frank Warmerdam wrote:

I have, for the time being, re-enabled the new user script. You might
want to use it promptly before Martin disables it again.

No, I won't disable it again. Anyhow I'd like to remind that, by
running this setup, you/we are putting the crown jewels of OSGeo's
authentication system at risk.

Think of it this way: If you look at bit closer, you'll realize that
the simple act of running PHP on whichever webserver is widely being
considered as a security hole in its own. I confess the statistics
might be a bit biased because of the many WordPress sites getting
hacked every day are counted in, but, anyhow, really sensitive sites
usually don't do this.

Now put a huge PHP-based web framework on top of that, containing more
PHP code than you probably ever read in your lifetime :wink:
I'd say that's an even bigger risk - and then take into account, that
the system in question was almost completely unmaintained. When I
looked at it yesterday evening, there were approx. 40 ! security
fixes pending - including updates to fix known issues in PHP and
OpenSSL.

And this site has scripts directly accessible ! from the Apache
webserver containing the core credentials for the LDAP authentication
system. Do you think that's reponsible ?

Setting up cool stuff is one side of the medal, maintaining the stuff
is the other side. If people are uncapable of maintaining that many
VM's, then I'd recommend not to run that many machines. As a short
term solution for the Python scripts in question I'd propose to
consider moving the LDAP credentials out of the main script(s) into a
separate place which is not accessible from the web server - and to
make use of some include directive in order to refer to these
credentials from the respective Python scripts.
An alternative might be to set a specific environment for the Python
and then to refer to the values of environment variables for the
credentials.

Personally I'm regularly checking the secure, backup, wiki and projects
VM for pending updates and I know Markus Neteler is doing the same for
a couple of VM's as well. In general I think it's reasonable to expect
from those who've been installing core services on any of the VM's to
maintain security updates there.

Cheers,
  Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------

2

On 12-04-09 11:00 PM, Martin Spott wrote:

On Mon, Apr 09, 2012 at 05:25:35PM -0700, Frank Warmerdam wrote:

I have, for the time being, re-enabled the new user script. You might
want to use it promptly before Martin disables it again.

No, I won't disable it again. Anyhow I'd like to remind that, by
running this setup, you/we are putting the crown jewels of OSGeo's
authentication system at risk.

...

Setting up cool stuff is one side of the medal, maintaining the stuff
is the other side.

Martin,

First, it isn't like I dropped in to have the fun of writing these
scripts and then rocketted away to do my next fun thing somewhere
else. I wrote the LDAP interface scripts to fulfill need(s) that
no one else filled, and then I babied them along over the following
years.

When we moved the LDAP server from osgeo1 to the secure VM I had hoped
to also move the LDAP interface scripts there, but was told that it was
too insecure to run an http server on that system. I might have left them
on osgeo1 until a more suitable home was found, but I vaguely recall that
osgeo1 was no longer able to reach the LDAP server in a way suitable for
the scripts after the migration so they had to be moved somewhere.

I *am* aware the webextra server isn't particularly secure but I don't
have a particularly good solution within my skill set. Frankly I think
the right solution is to run some sort of minimum exposure http server
on the secure VM but I have tried to respect the ruling of whoever forbade
running a web server there.

I wish your tone didn't always didn't always paint me in the light of
being lazy and stupid - even if you are convinced that is the case.

--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://home.gdal.org/warmerda
and watch the world go round - Rush | Geospatial Software Developer

3

On Tue, Apr 10, 2012 at 8:38 AM, Frank Warmerdam <warmerdam@pobox.com> wrote:

On 12-04-09 11:00 PM, Martin Spott wrote:

...

Besides insulting each other I would really appreciate that SAC made some
progress on closing the pending stuff:

- several VMs need to get upgraded since no more security updates are
  provided for Lenny. I fwd'ed this ahead of time, did one relevant machine
  myself (ride to hell due to unfortunate configuration) with then great help
  especially from Martin
- The move off Peer1 is pending for months and months. That machine is
   not receiving security updates for too long
- The Wiki needs LDAP integration since it is spammed to death, not really
   an impressive marketing
- security holes must be closed (no doubt, we got enough troubles in the past)
   - the LDAP script
   - No need to advertise Apache versions with patch levels on the Web (why
      invite crackers?)
- many SAC Wiki pages are outdated or incomplete

Maybe together with the SAC Chair we can define an action plan?

cheers
Markus

4

On Mon, Apr 09, 2012 at 11:38:48PM -0700, Frank Warmerdam wrote:

I wish your tone didn't always didn't always paint me in the light of
being lazy and stupid - even if you are convinced that is the case.

Frank, I wouldn't even think of calling you being "lazy", I'm just
convinced that your expertise (which I highly respect, honestly) covers
a considerably different field than mine does.
In fact, btw, I don't even know who actually put these Python scripts
onto the VM where they currently reside, given these permissions, I
just felt scared by this setup which I think should never have been
installed in this particular way.

I'm not fluent in Python, thus, even though I might be able to develop
a programmatic fix for these scripts by myself, I'd appreciate someone
else to take a stab at it who achieves a proper result more quickly.
Leaving a significant security hole open just because we don't have the
ressources to fix it properly isn't a good idea from my perspective.

Cheers,
  Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------

5

On Tue, Apr 10, 2012 at 1:26 AM, Martin Spott <Martin.Spott@mgras.net> wrote:

I'm not fluent in Python, thus, even though I might be able to develop
a programmatic fix for these scripts by myself, I'd appreciate someone
else to take a stab at it who achieves a proper result more quickly.
Leaving a significant security hole open just because we don't have the
ressources to fix it properly isn't a good idea from my perspective.

Martin,

I wrote the scripts, and I moved them to where they are.

As a short term solution for the Python scripts in question I'd propose to
consider moving the LDAP credentials out of the main script(s) into a
separate place which is not accessible from the web server - and to
make use of some include directive in order to refer to these
credentials from the respective Python scripts.

I don't really understand how we can put the credentials somewhere
not accessable from the web server but still accessable to the python
scripts which i presume run under the apache userid and permissions.

It seems to me that if the script can see them then apache can.
Or are you suggesting making the scripts setuid in some way?

BTW, you aren't suggesting that someone can just do an http fetch
to fetch the .py scripts, are you?

An alternative might be to set a specific environment for the Python
and then to refer to the values of environment variables for the
credentials.

Once again, this doesn't seem any more secure to me. Anyone who
can seize apache permissions will have it. And pushing it into the
environment for the whole web environment seems to be asking for
problems.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Software Developer

6

On Tue, Apr 10, 2012 at 1:24 AM, Markus Neteler <neteler@osgeo.org> wrote:

- several VMs need to get upgraded since no more security updates are
provided for Lenny. I fwd'ed this ahead of time, did one relevant machine
myself (ride to hell due to unfortunate configuration) with then great help
especially from Martin

Markus,

Yes, this is desirable. I'm avoiding this since I lack the expertise and
since you moved it can easily go wrong.

- The move off Peer1 is pending for months and months. That machine is
not receiving security updates for too long

To be clear, the action item is to move, not to apply security updates
to the peer1 server (IMHO).

- The Wiki needs LDAP integration since it is spammed to death, not really
an impressive marketing

By all means, I don't know what is holding us back, but I'd love to
see us put this in place, and from my point of view, I could not care
less about preserving existing wiki userids 94% of which are spambots.

- security holes must be closed (no doubt, we got enough troubles in the past)

In general desirable, yes.

- the LDAP script

What about the LDAP scripts? Just the security issue?

- No need to advertise Apache versions with patch levels on the Web (why
invite crackers?)

I can't imagine it takes much more effort for attackers to try all their
exploits against a server that doesn't announce it's version as opposed
to some subset against ones that do. I can't get excited about this
change myself.

- many SAC Wiki pages are outdated or incomplete

Certainly often the case, though it would be helpful to be more
specific.

Maybe together with the SAC Chair we can define an action plan?

I'm sure the SAC chair would also like volunteers.

From my perspective two things I'd like to see move ahead

are migration of the drupal services off peer1 to the new web
VM. This includes the main osgeo portal and the FDO and
MapGuide sites. We need someone conversant in Drupal to
do this. I'd prefer not to change Drupal versions due to the
extra complexity but others have other opinions.

Also, the migration of mailman to the mail VM. I took a crack
at this, and while the mailman part seemed to go ok, I botched
something with the underlying mail configuration (perhaps even
the DNS MX records) and had to back out. There isn't much
point in me trying again without the assistance of someone
good with mail configuration and debugging (IMHO).

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Software Developer

7

Hi Frank,

On Tue, Apr 10, 2012 at 08:57:54AM -0700, Frank Warmerdam wrote:

BTW, you aren't suggesting that someone can just do an http fetch
to fetch the .py scripts, are you?

No, not as a regular, planned operation :slight_smile:

As far as I can tell, the most common way to retrieve purportedly
hidden information is to trick the web server into a specific error
which exposes the content of the failing script (as debug output).
Both storing the credentials either in a separate file or in the
environment could help against this sort of attacks.
Aside from that, PHP is quite popular for exposing security holes
allowing to feed arbitrary (PHP) commands to be executed in the context
of the web server. Thus you're always better off storing sensitive
information outside the web server's document root and thus outside the
reach of the built-in PHP interpreter.

Anyhow, this still doesn't solve the issue resulting from the files
being world-readable and thus accessible for everybody having a
functional shell account on this VM. That's another item asking for
proper directory- and file-owners and -permissions.

Cheers,
  Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------

8

On Tue, Apr 10, 2012 at 09:04:38AM -0700, Frank Warmerdam wrote:

On Tue, Apr 10, 2012 at 1:24 AM, Markus Neteler <neteler@osgeo.org> wrote:

> - The Wiki needs LDAP integration since it is spammed to death, not really
> an impressive marketing

By all means, I don't know what is holding us back, but I'd love to
see us put this in place, and from my point of view, I could not care
less about preserving existing wiki userids 94% of which are spambots.

I managed to find the old thread where I'm summarizing the concerns:

  http://lists.osgeo.org/pipermail/sac/2011-September/003378.html

Cheers,
  Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------

9

On Tue, Apr 10, 2012 at 9:26 AM, Martin Spott <Martin.Spott@mgras.net> wrote:

On Tue, Apr 10, 2012 at 09:04:38AM -0700, Frank Warmerdam wrote:

On Tue, Apr 10, 2012 at 1:24 AM, Markus Neteler <neteler@osgeo.org> wrote:

> - The Wiki needs LDAP integration since it is spammed to death, not really
> an impressive marketing

By all means, I don't know what is holding us back, but I'd love to
see us put this in place, and from my point of view, I could not care
less about preserving existing wiki userids 94% of which are spambots.

I managed to find the old thread where I'm summarizing the concerns:

http://lists.osgeo.org/pipermail/sac/2011-September/003378.html

Martin,

I continue to be of the opinion that we don't need to do any of the things
suggested in that thread.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Software Developer

10

On Tue, Apr 10, 2012 at 9:19 AM, Martin Spott <Martin.Spott@mgras.net> wrote:

As far as I can tell, the most common way to retrieve purportedly
hidden information is to trick the web server into a specific error
which exposes the content of the failing script (as debug output).
Both storing the credentials either in a separate file or in the
environment could help against this sort of attacks.
Aside from that, PHP is quite popular for exposing security holes
allowing to feed arbitrary (PHP) commands to be executed in the context
of the web server. Thus you're always better off storing sensitive
information outside the web server's document root and thus outside the
reach of the built-in PHP interpreter.

Martin,

OK - while this doesn't sound compelling, I can see moving the value
into a file outside the document root would mitigate some risk. I'll do
it today.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Software Developer

11

On Tue, Apr 10, 2012 at 9:35 AM, Frank Warmerdam <warmerdam@pobox.com> wrote:

On Tue, Apr 10, 2012 at 9:19 AM, Martin Spott <Martin.Spott@mgras.net> wrote:

As far as I can tell, the most common way to retrieve purportedly
hidden information is to trick the web server into a specific error
which exposes the content of the failing script (as debug output).
Both storing the credentials either in a separate file or in the
environment could help against this sort of attacks.
Aside from that, PHP is quite popular for exposing security holes
allowing to feed arbitrary (PHP) commands to be executed in the context
of the web server. Thus you're always better off storing sensitive
information outside the web server's document root and thus outside the
reach of the built-in PHP interpreter.

Martin,

OK - while this doesn't sound compelling, I can see moving the value
into a file outside the document root would mitigate some risk. I'll do
it today.

Folks,

OK, the change is made. The LDAP python scripts read a credentials
file outside the the doc root (and outside cgi-bin which wasn't under the
docroot). Note that the master ldap password is also in the svn history
for the osgeo scripts which lives in some sort of non-public svn service.

I would suggest at some point we update the master ldap password.
In addition to the credentials file on www2 I think we would also need
to update Drupal which I think has this password. I do not know how
to do that off hand.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Software Developer

12

On Tue, Apr 10, 2012 at 10:46:58AM -0700, Frank Warmerdam wrote:

OK, the change is made. The LDAP python scripts read a credentials
file outside the the doc root (and outside cgi-bin which wasn't under the
docroot). Note that the master ldap password is also in the svn history
for the osgeo scripts which lives in some sort of non-public svn service.

Thanks, Frank. Are you certain there are no publicly visible
changelogs of the respective SVN history ?

Cheers,
  Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------

13

Martin,

No, I am not certain. I didn't set up the OSGeo "admin" svn server -
I think Howard did. I've just tried to follow the practice that was
established. I have always felt a bit queasy about it.

Best regards,

On Wed, Apr 11, 2012 at 12:17 PM, Martin Spott <Martin.Spott@mgras.net> wrote:

On Tue, Apr 10, 2012 at 10:46:58AM -0700, Frank Warmerdam wrote:

OK, the change is made. The LDAP python scripts read a credentials
file outside the the doc root (and outside cgi-bin which wasn't under the
docroot). Note that the master ldap password is also in the svn history
for the osgeo scripts which lives in some sort of non-public svn service.

Thanks, Frank. Are you certain there are no publicly visible
changelogs of the respective SVN history ?

Cheers,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------
_______________________________________________
Sac mailing list
Sac@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/sac

--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Software Developer

14

On Tue, Apr 10, 2012 at 09:30:03AM -0700, Frank Warmerdam wrote:

On Tue, Apr 10, 2012 at 9:26 AM, Martin Spott <Martin.Spott@mgras.net> wrote:

> I managed to find the old thread where I'm summarizing the concerns:
>
> http://lists.osgeo.org/pipermail/sac/2011-September/003378.html

I continue to be of the opinion that we don't need to do any of the things
suggested in that thread.

Translating this into different words, you suggest to purge Wiki
content which had been written by real humans with serious intent.
Does everybody agree on this proposal ?

Cheers,
  Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------

15

On Fri, Apr 13, 2012 at 12:48 PM, Martin Spott <Martin.Spott@mgras.net> wrote:

On Tue, Apr 10, 2012 at 09:30:03AM -0700, Frank Warmerdam wrote:

On Tue, Apr 10, 2012 at 9:26 AM, Martin Spott <Martin.Spott@mgras.net> wrote:

> I managed to find the old thread where I'm summarizing the concerns:
>
> http://lists.osgeo.org/pipermail/sac/2011-September/003378.html

I continue to be of the opinion that we don't need to do any of the things
suggested in that thread.

Translating this into different words, you suggest to purge Wiki
content which had been written by real humans with serious intent.
Does everybody agree on this proposal ?

Martin,

To be clear, I am suggesting we lose the connection between who contributed
the content and LDAP users. I am not suggesting purging any content, and I
am not clear on where this idea came from.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Software Developer

16

On Fri, Apr 13, 2012 at 12:51:28PM -0700, Frank Warmerdam wrote:

On Fri, Apr 13, 2012 at 12:48 PM, Martin Spott <Martin.Spott@mgras.net> wrote:
> On Tue, Apr 10, 2012 at 09:30:03AM -0700, Frank Warmerdam wrote:
>> On Tue, Apr 10, 2012 at 9:26 AM, Martin Spott <Martin.Spott@mgras.net> wrote:
>
>> > I managed to find the old thread where I'm summarizing the concerns:
>> >
>> > http://lists.osgeo.org/pipermail/sac/2011-September/003378.html
>
>> I continue to be of the opinion that we don't need to do any of the things
>> suggested in that thread.
>
> Translating this into different words, you suggest to purge Wiki
> content which had been written by real humans with serious intent.
> Does everybody agree on this proposal ?

To be clear, I am suggesting we lose the connection between who contributed
the content and LDAP users. I am not suggesting purging any content, and I
am not clear on where this idea came from.

User pages refer to textual user logins. If you change users' login
names, their previous user pages will be lost. This context was
explained in:

  http://lists.osgeo.org/pipermail/sac/2011-September/003378.html

Cheers,

  Martin - trying to develop a solution on his own ....
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------

17

On Fri, Apr 13, 2012 at 9:51 PM, Frank Warmerdam <warmerdam@pobox.com> wrote:

I am not suggesting purging any content, and I
am not clear on where this idea came from.

Perhaps my idea: remove all this spam rubbish...

Best
Markus (still wondering why this bot mess hardly happens
             on the GRASS Mediawiki, there must still be some
             difference in the anti-spam measures)

18

On Thu, May 10, 2012 at 12:19 PM, Martin Spott <Martin.Spott@mgras.net> wrote:

User pages refer to textual user logins. If you change users' login
names, their previous user pages will be lost. This context was
explained in:

http://lists.osgeo.org/pipermail/sac/2011-September/003378.html

Martin,

Are you suggesting that pages like:

  http://wiki.osgeo.org/wiki/User:Arnulf_Christl

have a different existance than a page like:

  http://wiki.osgeo.org/wiki/Mark_Lucas

which is not in the "User:" domain? Will anything with the User:
prefix be lost (as opposed to just orphaned) if we aren't careful?
Perhaps we could/should remap the User:x pages to just x or perhaps
User_x?

I personally don't really care too much about whether the current
User: pages remain the "user home page" for folks after a transition
but I don't want the content lost.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Software Developer