Topic: Issues with 0666-mode shared memory

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.

Re: Issues with 0666-mode shared memory

Hi,

Yes but it's fixed in CVS... current directory is keeped in private memory of the process smile

Re: Issues with 0666-mode shared memory

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?

Re: Issues with 0666-mode shared memory

Yes i'm still using 0666...

If we use 0600 rights it should be better no ? (i'm not at home so i can't try anything sad )

Re: Issues with 0666-mode shared memory

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.