1

(13 replies, posted in Others)

For your information, the security community has assigned identifier CVE-2013-4176 to this issue on the oss-security mailing list (thread 10678) in the mean time.

2

(4 replies, posted in Others)

I'm not sure if 0600 still works after the processes have dropped their privileges, not tested though. Also, the fact that an unprivileged user might still register the same shared memory region before any mysecureshell process created it, might be a problem leading to denial of service again. It could be interesting to see, how other pieces of software register shared memory to avoid that problem. Maybe let's discuss this on a synchronous medium (phone, chat), instead.


For your information, the security community has assigned identifier CVE-2013-4175 to this issue on the oss-security mailing list (thread 10679) in the mean time.

3

(4 replies, posted in Others)

current directory is keeped in private memory of the process smile

Can you point me to the code changes that you are referring to?

Yes but it's fixed in CVS...

According to the CVS web view, shared memory is still using 0666 mode:
http://mysecureshell.cvs.sourceforge.ne … markup#l73

Is that the latest code?

4

(13 replies, posted in Others)

Yes, it breaks that and more. I'm fully aware you don't want to apply that patch to CVS. But it might work for some users that can make the trade-off for instant security.

5

(13 replies, posted in Others)

PS: If anyone would want to make a Debian package for a version not using shared memory that would be:

sudo apt-get install devscripts build-essential debhelper libacl1-dev libssl-dev fakeroot
wget http://mysecureshell.free.fr/repository/index.php/debian/pool/main/m/mysecureshell/mysecureshell_1.31.tar.gz
wget http://www.hartwork.org/public/mysecureshell-1.31-no-shared-memory.patch
tar xf mysecureshell_1.31.tar.gz
 
cd mysecureshell-1.31/
patch -p1 < ../mysecureshell-1.31-no-shared-memory.patch
dch -v 1.31+noshm 'Apply patch to stop using shared memory'
 
debuild -us -uc
sudo dpkg -i ../mysecureshell_1.31+noshm_amd64.deb

mysecureshell (version 1.31) is using shared memory. At creation time, mode 0666 is applied so that any unprivileged user can write to it.
For instance, I could mark all empty slots occupied to reduce overall availability of the service, eventually down to zero.

To demonstrate the issue, I have written a small command line tool. It's free software and can be found at GitHub by now.  Use it like this:

# make
cc -std=c99 -Wall -Wextra -pedantic local-dos.c -o local-dos

# ./local-dos
USAGE:
  ./local-dos (block|unblock|show)

# watch -n 1 -d ./local-dos block
[..]

Besides the local DoS, it might be possible to attack the call to chdir, since that is reading from shared memory, too.

7

(13 replies, posted in Others)

The problem is lack of synchronisation with access to the shared memory. The current code

for (i = 0; i < SFTPWHO_MAXCLIENT; i++)
    if (who[i].status == SFTPWHO_EMPTY)
    {
        (void) usleep(100);
        if (who[i].status == SFTPWHO_EMPTY)
        {
            //clean all old infos
            memset(&who[i], 0, sizeof(*who));
            //marked structure as occuped 
            who[i].status = SFTPWHO_IDLE;
            return (&who[i]);
        }
    }

has a race condition that allows two processes to occopy the same slot.

pthread mutexes with attribute PTHREAD_PROCESS_SHARED do not seem to work in case of mysecureshell, since its mysecureshell processes are not related. POSIX semaphores using sem_open(3) may work.


For users not depending on mysecureshell features like bandwidth limitation, this patch removing use of shared memory might be an acceptable fix for the moment.

8

(5 replies, posted in Others)

Okay... why? If you are using Git or so locally why not publish that repository instead?
Would you lose anything pushing your current code up to CVS?

With status quo, I am going to write patches against code that might not even be up to date any more. That doesn't sound right.

9

(5 replies, posted in Others)

configure should go into the tarball, absolutely. But in CVS? Basically everyone moved away from keeping configure in CVS at some point.

I don't see configure.ac in CVS yet. Am I looking at the wrong place?
http://mysecureshell.cvs.sourceforge.ne … cureshell/

It seems CVS still has the old version:
http://mysecureshell.cvs.sourceforge.ne … c?view=log

Please apply the patch :-)

11

(5 replies, posted in Others)

Hello!

The configure script in CVS says:

# Generated by GNU Autoconf 2.68 for MySecureShell 1.31.

If that's true, please

  • Add the source file configure.ac to CVS

  • Remove the generate file configure from CVS

Thank you!

12

(13 replies, posted in Others)

Any updates on a fix?

Please apply this patch to CVS:

diff --git a/SftpServer/FileSystemAcl.c b/SftpServer/FileSystemAcl.c
index 8c74fde..90d571e 100644
--- a/SftpServer/FileSystemAcl.c
+++ b/SftpServer/FileSystemAcl.c
@@ -150,7 +150,7 @@ int FSEnumAcl(const char *file, int resolvePath, void (*callback)(void *data, in
                {
                        int mode;
 
-                       mode = (acls[i].a_perm & 2) ? SSH5_ACE4_READ_DATA : 0) |
+                       mode = ((acls[i].a_perm & 2) ? SSH5_ACE4_READ_DATA : 0) |
                         ((acls[i].a_perm & 4) ? SSH5_ACE4_WRITE_DATA : 0) |
                         ((acls[i].a_perm & 1) ? SSH5_ACE4_EXECUTE : 0);
                        switch (acls[i].a_type)

I am actually surprised, that the current code compiles. I have tried adding more (unbalanced) braces and it still compiles. Holy cow :-)