Have something to say?

Ready to be published? LXer is read by around 350,000 individuals each month, and is an excellent place for you to publish your ideas, thoughts, reviews, complaints, etc. Do you have something to say to the Linux community?

A busy week for the Zope team: on Monday another security alert was
released revealing a potential problem found by Peter Kelly. This
problem involved incorrect protection of data updating for Image and
File objects: any user with DTML editing privileges could update the
File or Image object data directly.

New slocate packages are availble for Red Hat Linux 6.x and Red Hat
Linux 7. These fix a problem with the database parsing code in slocate.
(slocate was not shipped with Red Hat Linux prior to version 6.0, so
earlier versions are not affected.)

Last week a Zope (security advisory was released which indicated
Erik Enge found a problem in the way Zope calculates roles. In some
situations Zope checked the wrong folder hierarchy which could
cause it to grant local roles when it should not. In other words:
users with privileges in one folder could gain privileges in
another folder.

Michel Kaempf reported a security problem in slocate (a secure version
of locate, a tool to quickly locate files on a filesystem) on bugtraq
which was originally discovered by zorgon. He discovered there was
a bug in the database reading code which made it overwrite a internal
structure with some input. He then showed this could be exploited
to trick slocate into executing arbitrary code by pointing it to a
carefully crafted database.

The problem that was previously reported for joe also occurs with
other editors. When nano (a free pico clone) unexpectedly dies
it tries a warning message to a new file with a predictable name
(the name of the file being edited with ".save" appended). Unfortunately
that file was not created safely which made nano vulnerable to a
symlink attack.

Colin Phipps found an interesting symlink attack problem in fsh (a
tool to quickly run remote commands over rsh/ssh/lsh). When fshd
starts it creates a directory in /tmp to hold its sockets. It tries
to do that securely by checking of it can chown that directory if
it already exists to check if it is owner by the user invoking it.
However an attacker can circumvent this check by inserting a
symlink to a file that is owner by the user who runs fhsd and
replacing that with a directory just before fshd creates the
socket.