LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (https://www.linuxquestions.org/questions/slackware-14/)
-   -   [Slackware security] vulnerabilities outstanding 20140101 (https://www.linuxquestions.org/questions/slackware-14/%5Bslackware-security%5D-vulnerabilities-outstanding-20140101-a-4175489800/)

mancha 01-01-2014 11:53 AM

[Slackware security] vulnerabilities outstanding 20140101
 
Hello.

Some vulnerabilities of varying severity...

  1. curl 7.34.0
    CVE-2013-4545 fixed.
    CVE-2013-6422 fixed.

  2. php 5.4.23
    CVE-2013-6420 fixed.

  3. libgcrypt 1.6.0
    CVE-2013-4576 fixed.
    There's a secondary mitigant relevant to gnupg2 in libgcrypt (see: http://seclists.org/oss-sec/2013/q4/523).

  4. samba 4.1.3
    CVE-2013-4408 fixed.
    CVE-2012-6150 fixed.

  5. xorg-server
    CVE-2013-6424 fixed in http://patchwork.freedesktop.org/patch/14769/

  6. pixman
    CVE-2013-6425 fixed in http://cgit.freedesktop.org/pixman/p...d=5e14da97f16e

  7. openssl
    CVE-2013-6449 fixed in http://git.openssl.org/gitweb/?p=ope...h;h=ca989269a2
    CVE-2013-6450 fixed in http://git.openssl.org/gitweb/?p=ope...h;h=34628967f1

--mancha

mancha 01-06-2014 11:49 AM

Update 20140106
  1. openssl 1.0.1f
    CVE-2013-6449 fixed.
    CVE-2013-6450 fixed.
    CVE-2013-4353 fixed.

    Also, gmt_unix_time (seconds since epoch) is no longer added to the random fields of {Client,Server}Hello because that can be used for host fingerprinting by an adversary.
--mancha

mancha 01-07-2014 12:19 PM

Update 20140107
  1. libXfont
    CVE-2013-6462 fixed in http://cgit.freedesktop.org/xorg/lib...d=4d024ac10f96

    Above patch applies cleanly to Slackware 14.1's libXfont 1.4.6. Note: X.Org released libXfont 1.4.7 on 20140107
    to address this vulnerability.
--mancha

mats_b_tegner 01-07-2014 04:24 PM

Quote:

Originally Posted by mancha (Post 5092961)
Update 20140106
  1. openssl 1.0.1f
    CVE-2013-6449 fixed.
    CVE-2013-6450 fixed.
    CVE-2013-4353 fixed.

    Also, gmt_unix_time (seconds since epoch) is no longer added to the random fields of {Client,Server}Hello because that can be used for host fingerprinting by an adversary.
--mancha

Compilation fails when building the docs with Perl 5.18. Use the following patch from LFS on the 0.9.8y-sources:
http://www.linuxfromscratch.org/patc...syntax-1.patch

And then this patch from Gentoo on 1.0.1f:
http://sources.gentoo.org/cgi-bin/vi...ch?view=markup

Mats

mancha 01-07-2014 10:18 PM

Quote:

Originally Posted by mats_b_tegner (Post 5093798)
Compilation fails when building the docs with Perl 5.18. Use the following patch from LFS on the 0.9.8y-sources:
http://www.linuxfromscratch.org/patc...syntax-1.patch

And then this patch from Gentoo on 1.0.1f:
http://sources.gentoo.org/cgi-bin/vi...ch?view=markup

Thanks for that. The LFS patch doesn't apply to 0.9.8y here so I made one from scratch. I also took the Gentoo patch you linked and reformatted it a bit. Both patches are here:

openssl-0.9.8y-perl-5.18.diff
openssl-1.0.1f-perl-5.18.diff


--mancha

mats_b_tegner 01-09-2014 06:10 AM

Quote:

Originally Posted by mancha (Post 5093989)
Thanks for that. The LFS patch doesn't apply to 0.9.8y here so I made one from scratch. I also took the Gentoo patch you linked and reformatted it a bit. Both patches are here:

openssl-0.9.8y-perl-5.18.diff
openssl-1.0.1f-perl-5.18.diff


--mancha

I've rebuilt the openssl-packages with your patches and they apply without errors.

mats_b_tegner 01-09-2014 06:14 AM

I've upgraded curl, php and samba to their latest versions. Just download the sources and compile using the SlackBuild-scripts from /source. Should we notify PatV?

mancha 01-09-2014 03:19 PM

Quote:

Originally Posted by mats_b_tegner (Post 5094840)
I've upgraded curl, php and samba to their latest versions. Just download the sources and compile using the SlackBuild-scripts from /source. Should we notify PatV?

Glad to hear my patches worked out for you.

I emailed Pat about a week and a half before starting this thread but I haven't sent a 2nd email with more recent news (e.g. openssl, libxfont). A new email might be worthwhile in case he's not visiting LQ. Feel free to send one.

--mancha

sardinha 01-10-2014 07:01 AM

samba 4.1.4
 
The last stable released of samba is version 4.1.4: http://www.samba.org/samba/history/samba-4.1.4.html

The previous version (4.1.3) resolved some security holes, but maybe worth have the last release with more bug fixes.

corvid 01-10-2014 10:37 AM

I appreciate that you're keeping on top of the security issues.

Given how single-point-of-failure it is having Pat in control and these things often going unfixed for so long, it's really looking like I'm going to have to move on from slackware at last.

mats_b_tegner 01-12-2014 06:58 AM

PHP 5.5.24 has been released. No security fixes as far as I know, but it's a recommended upgrade:

http://www.php.net/ChangeLog-5.php#5.4.24

Mats

hpfeil 01-12-2014 11:51 AM

Bye, corvid! Remember to write if you find work and hang by your thumbs. [Bob & Ray Radio Program sign-off] I'll move on when Pat does. He's done fine with me for twenty years. I've tried the rest, but still use the best.

Thank you, mancha for staying on top of the SSL security patches. (Openssl-1.0.1e is the version on the mirrors.)

hitest 01-12-2014 12:22 PM

Quote:

Originally Posted by corvid (Post 5095552)
I appreciate that you're keeping on top of the security issues.

Given how single-point-of-failure it is having Pat in control and these things often going unfixed for so long, it's really looking like I'm going to have to move on from slackware at last.

Okay. But, why announce that you're leaving?
I hope that you find a distro that is more to your liking.

metaschima 01-12-2014 01:11 PM

If you look at the patches, few of them are actually security vulnerabilities, and none of them are critical. I'm sure Pat V. would have pushed updates if any of them were critical security vulnerabilities.

In other words, don't let this thread chase you away from Slackware.

gnupg 1.x is up-to-date at 1.4.16 BTW.

dugan 01-12-2014 02:44 PM

Quote:

Originally Posted by corvid (Post 5095552)
these things often going unfixed for so long

What are you talking about?

ponce 01-13-2014 05:22 AM

(this is not a follow-up to to Dugan/corvid)
Quote:

Originally Posted by mancha (Post 5095121)
libxfont

this is really amazing: a bug in the X code since 1991, fixed in libXfont-1.4.7 (alternate patch)
https://twitter.com/hackerfantastic/...104448/photo/1 (via sid77)
http://lists.x.org/archives/xorg-ann...ry/002389.html

metaschima 01-13-2014 11:19 AM

I request the name of this thread be changed to something less likely to drive away Slackware users. These are NOT all security vulnerabilities, they are NOT all outstanding, and they are NOT critical.

In fact, I don't see why you don't submit these to Pat V. himself, if you believe they are so important. He might not even see them here.

unSpawn 01-13-2014 05:46 PM

Quote:

Originally Posted by metaschima (Post 5097269)
I request the name of this thread be changed to something less likely to drive away Slackware users.

Given previous contributions to this thread, as in evidence of slackers not being driven away, I decline to do so.

metaschima 01-13-2014 06:19 PM

Quote:

Originally Posted by unSpawn (Post 5097472)
Given previous contributions to this thread, as in evidence of slackers not being driven away, I decline to do so.

If corvid posts again (that was his last post), then I'll believe it.

mancha 01-13-2014 07:58 PM

Quote:

Originally Posted by metaschima (Post 5097269)
These are NOT all security vulnerabilities, they are NOT all outstanding, and they are NOT critical.

These vulnerabilities are outstanding as of 20140113 and have security implications of varying degree. Claiming otherwise, as you've done twice now, is confusing to readers who might inadvertently believe you.

Quote:

Originally Posted by metaschima (Post 5096739)
In other words, don't let this thread chase you away from Slackware.

Quote:

Originally Posted by metaschima (Post 5097488)
If corvid posts again (that was his last post), then I'll believe it.

It's clear corvid's comment has given you the jitters. I wish he'd not made it here because as a result the thread is now more noise than signal (BTW, he made a similar comment in January 2012).

But, you've got it backwards. Raising awareness, sharing information, and most importantly providing solutions for these issues, makes Slackware and its community stronger, not weaker.

--mancha

metaschima 01-13-2014 08:15 PM

Have you submitted these to Pat V. ? If not, send him an e-mail.

I'm wondering where the other Slackware devs are, and what their comments on these issues are. I request at least that, otherwise this thread doesn't look right, and I don't like that. Slackware is a great distro and I don't like the image it is getting here in this thread. Maybe that wasn't the original intent, but that's what it is now.

Thom1b 01-14-2014 12:06 AM

bind-9.9.4_P2
 
bind-9.9.4_P2 has been released and is highly recommended to upgrade.

https://kb.isc.org/article/AA-01078

guanx 01-14-2014 03:34 AM

Quote:

Originally Posted by metaschima (Post 5097269)
I request the name of this thread be changed to something less likely to drive away Slackware users.
...

I guess those who are smart enough to find and read this forum can't be driven away so easily. -- Just my guess.

drmozes 01-14-2014 05:10 AM

Quote:

Originally Posted by mancha (Post 5097521)
But, you've got it backwards. Raising awareness, sharing information, and most importantly providing solutions for these issues, makes Slackware and its community stronger, not weaker.

I can see both sides here - but ultimately I agree with mancha because as the user/maintainer of a system running Slackware, I'd rather be aware of the current potential security issues (whatever their severity) and decide what to do about them, whilst I am awaiting an update in the Slackware tree. After all, if I have to rebuild a system that was compromised, that's going to take me a *lot* longer than preparing a patch myself or a short term work-around.

Patrick has now released the updates.

metaschima 01-14-2014 11:49 AM

These packages have been updated:
http://www.slackware.com/security/li...ecurity&y=2014
So take them off the list.

I also recommend that you post more information about each vulnerability instead of just " CVE-2013-4545 fixed.". Post what the fix does and how severe it is. I'm sure you want something that will benefit Slackware, so putting accurate, detailed information is much less likely to scare off users. At least post a link to the page that describes the problem and fix, and rate its severity.

hpfeil 01-15-2014 10:45 AM

Security of your system is your responsibility, not Master Volkerding's. Seasoned systems administrators are current with the entries in https://isc.sans.edu/diary.html, and probably have read at least a few of the security-related white papers at SANs. In fact, there is enough information on that site to become qualified as a security expert, but if that's your goal, sign up for classes at http://www.sans.edu/ Be proactive.

For more in-depth information on CERT advisories, follow the links at:
ftp://ftp.osuosl.org/pub/slackware/s.../ChangeLog.txt

mancha 01-29-2014 05:01 PM

Update 20140129

For those wishing to address CVE-2013-6424 & CVE-2013-6425 by re-building xorg-server and pixman, I've placed patches at the vault:
  1. xorg-server-1.14.3_CVE-2013-6424.diff (sig)
  2. pixman-0.30.2_CVE-2013-6425.diff (sig)
Building xorg-server and pixman can get a little hairy so I've also made Slackware 14.1 32-bit and 64-bit packages available:
  1. Slackware-14.1-CVE-2013-6424+6425.tar (sig) [32-bit]
  2. Slackware64-14.1-CVE-2013-6424+6425.tar (sig) [64-bit]
Note: upgrading xorg-server packages will overwrite proprietary video drivers so if you use those you'll need to re-install them after the upgrade.

Finally, I am providing CVE-2013-6425.ods, a LibreOffice spreadsheet proof-of-concept thanks to Ubuntu, which shows the DoS against X. Make sure you've saved everything you're working on before doing this because it'll crash the X server:

Code:

$ scalc CVE-2013-6425.ods
--mancha

metaschima 01-30-2014 11:21 AM

Well, that's more like it. I can see now that you are actually trying to help Slackware users. Providing patches and packages to fix these issues, and even a proof-of-concept is a great thing.

I apologize for doubting your good intentions earlier. May I recommend that you make your intentions more clear in your initial posts by explaining a bit about what you are trying to achieve. Writing a short statement about your concern on outstanding vulnerabilities, links to explanations of the vulnerabilities, saying that you e-mailed Mr. Pat V with them, and saying that you wish to help users resolve these vulnerabilities would do wonders on how people interpret your thread. Like 2 sentences is all it takes, and there won't be any more confusion. Again, I understand now that your intentions are good, but only after this last post.

Lastly, just so people don't get me wrong, I would like to say that Slackware is a great distro, the best I've tried. I would like to help it out as much as I can, and I don't like to see its name tarnished. I reacted the way I did, because the intentions of the thread were unclear to me. Maybe they were clear to others. I guess maybe it is because I'm new here, and I don't know exactly how things are done.

gnashley 01-30-2014 12:51 PM

I say let the 'man from Mancha' continue however he sees fit. He's been doing great work around here for a while now which is much appreciated.

hpfeil 01-30-2014 02:57 PM

Er, the sky is not falling, yet.

"Integer underflow in the pixman_trapezoid_valid macro in pixman.h in Pixman before 0.32.0, as used in X.Org server and cairo, allows context-dependent attackers to cause a denial of service (crash) via a negative bottom value."

We are already running 0.32.0. The vulnerable version was 0.30.0. BTW, who has the Intel Xorg driver installed? That isn't what Slackware distributed on November 8, 2013. We already have the fixed pixman.h in pixman and xorg. Here's the patch that was applied last October: http://lists.x.org/archives/xorg-dev...er/037996.html

https://cve.mitre.org has re-vamped their website. A lot of legacy incidents appear to be new, but upon further investigation, you'll find they were closed last year.

Just to be safe, though, I'm keeping my aluminum foil "Tin Woodman" hat within reach.

hpfeil 01-30-2014 03:22 PM

Perhaps I spoke too soon. Although I'm running pixman 32.2, doesn't mean that's the version in Slackware-Current.

http://lists.freedesktop.org/archive...er/003119.html

The Man! La Mancha rocks! Thanks for posting the updates. Building xorg from source is not a task for the faint of heart.

I said "faint of heart" because I fainted while reading this: http://www.x.org/wiki/Building_the_X_Window_System/

mancha 01-31-2014 05:36 AM

Update 20140131

This updates my curl advisory in post #1 of this thread.
  1. curl 7.35.0

    CVE-2014-0015 fixed
    CVE-2013-6422 fixed (since 7.34.0)
    CVE-2013-4545 fixed (since 7.33.0)
--mancha

BrZ 01-31-2014 12:43 PM

Hi mancha, a new serious kernel bug (CVE-2014-0038) affecting _all_ versions since 3.4. Second patch seems the correct and was merged here.

55020 01-31-2014 01:13 PM

AFAICT this is graded "Don't Panic". http://seclists.org/oss-sec/2014/q1/187 says it affects only x32 -- which is that weird hybrid 32-bit address space with AMD64 instructions that nobody uses. Especially not Slackware. The vuln goes back to 3.4, because 3.4 is when x32 was merged...

Edit: Wrong wrong wrong! :( see metaschima's post below.

metaschima 01-31-2014 01:20 PM

Quote:

Originally Posted by BrZ (Post 5108830)
Hi mancha, a new serious kernel bug (CVE-2014-0038) affecting _all_ versions since 3.4. Second patch seems the correct and was merged here.

I was just about to post this. It really does look serious and x32 is enabled in slackware64 kernels.

Luckily I have a custom kernel that is pure 64-bit.

EDIT:
It looks like slackware64 glibc is NOT built with x32 support. So I guess maybe it isn't so bad after all. The user would have to build glibc with x32 support and then run a compromised x32 program.

55020 01-31-2014 01:38 PM

Quote:

Originally Posted by metaschima (Post 5108852)
I was just about to post this. It really does look serious and x32 is enabled in slackware64 kernels.

Eek! Thanks! You're right: CONFIG_X86_X32=y
I hereby withdraw that "Don't Panic" grading. Sorry!

mancha 01-31-2014 02:08 PM

Quote:

Originally Posted by BrZ (Post 5108830)
Hi mancha, a new serious kernel bug (CVE-2014-0038) affecting _all_ versions since 3.4. Second patch seems the correct and was merged here.

Hi BrZ.

Thanks for raising visibility of this issue.

I confirm I am able to oops Slackware64 14.1's kernel (system is stock Slackware64-14.1):

Code:

[ 3625.853465] BUG: unable to handle kernel NULL pointer dereference at 0000000000000009
[ 3625.853465] IP: [<ffffffff81a73c1d>] __sys_recvmmsg+0x2d/0x260
[ 3625.853465] PGD b6d1067 PUD 4514067 PMD 0
[ 3625.853465] Oops: 0000 [#1] SMP

The fix applies successfully to Slackware 14.1's 3.10.17 kernel (with slight offset but that's OK).

This issue only affects 64-bit Slackware (14.1 and -current). 32-bit Slackware is unaffected.

ɐɥɔuɐɯ--

volkerdi 01-31-2014 03:35 PM

Quote:

Originally Posted by 55020 (Post 5108864)
Eek! Thanks! You're right: CONFIG_X86_X32=y
I hereby withdraw that "Don't Panic" grading. Sorry!

Ah, but CONFIG_X86_X32_ABI is not set. Apparently ld isn't handling x86_32 properly, so the kernel didn't enable that option. Accidentally not vulnerable. :)

Since I'm here, in cases like the pixman/X server trapazoid bug which can lead to a crash but not privilege escalation, I'm inclined to look at it as a bug rather than a security issue even though it was assigned a CVE. It's not in the same realm as something like the libXfont overflow.

mancha 01-31-2014 04:06 PM

Quote:

Originally Posted by volkerdi (Post 5108933)
Ah, but CONFIG_X86_X32_ABI is not set. Apparently ld isn't handling x86_32 properly, so the kernel didn't enable that option. Accidentally not vulnerable. :)

Hi Pat. I believe Slackware64 14.1 & current are vulnerable (see my oops in the post just above yours).

CONFIG_X86_X32_ABI is a compile-time option which is set after confirming ld can emulate elf32_x86_64.
You can check Slack's ld supported emulations with:

Code:

$ ld -V
The actual kernel test is something like this:

Code:

echo '1: .quad 1b' | gcc -c -xassembler -o blah - && objcopy -O elf32-x86-64 blah blah.o && ld -m elf32_x86_64 blah.o -o blah; echo $?
ɐɥɔuɐɯ--

mancha 01-31-2014 04:57 PM

Pat:

I won't be able to check this for the next few hours, but a quick double-check you can do is:

Code:

# cd /usr/src/linux-3.10.17
# make V=1

Let that run a bit and see if the option is being set (-DCONFIG_X86_X32_ABI).

--mancha

volkerdi 01-31-2014 06:08 PM

Quote:

Originally Posted by mancha (Post 5108965)

Let that run a bit and see if the option is being set (-DCONFIG_X86_X32_ABI).

--mancha

Ah, I see. It is there at compile time, but not in the .config.

Is there actually any interest in x86_x32? If the toolchain doesn't fully support it and nobody's using it for anything, perhaps the path of least resistance would be to turn off CONFIG_X86_X32 in the kernel entirely.

metaschima 01-31-2014 06:20 PM

Full use of x32 requires x32 glibc, gcc, gdb, and ld (binutils). If these are not provided (and they are not), then there is no reason to enable x32 in the kernel.
https://sites.google.com/site/x32abi/

The proof of concept by mancha doesn't use glibc, but rather assembly ... which is clever.

mancha 02-01-2014 04:43 AM

Quote:

Originally Posted by volkerdi (Post 5108997)
Is there actually any interest in x86_x32? If the toolchain doesn't fully support it and nobody's using it for anything, perhaps the path of least resistance would be to turn off CONFIG_X86_X32 in the kernel entirely.

The API never really took off so my hunch is very few, if any, will notice if you remove it. Then again, no one misses the water till the well runs dry.

Quote:

Originally Posted by volkerdi (Post 5108933)
Since I'm here, in cases like the pixman/X server trapazoid bug which can lead to a crash but not privilege escalation, I'm inclined to look at it as a bug rather than a security issue even though it was assigned a CVE.

The pixman vulnerability seems limited to denial of service. I'm not familiar with the EXA acceleration code in xorg-server so without code review I have no idea if there's potential to leverage the wraparound for things like code execution. To be honest I didn't dwell on it. X runs as root; the fix is trivial; why risk it?

ɐɥɔuɐɯ--

mancha 02-02-2014 09:57 PM

Update 20140202

ALERT: CVE-2014-0038 is no longer merely theoretical. A working Ubuntu exploit was made public by Rebel. I can confirm
the exploit methodology does work on Slackware64 14.1+.

Given the exposure, I authored a kernel module which protects against this attack and which I now share with the Slackware
community.

To get it working, as root do:

Code:

# tar xf nox32recvmmsg.tar.bz2
# cd nox32recvmmsg
# make
# insmod nox32recvmmsg.ko

--mancha

EDIT: The kernel module has undergone two revisions since the original post. See follow-up posts for more info.
Make sure the tarball you downloaded is the most recent. Compare to hash:

SHA256(nox32recvmmsg.tar.bz2)= 8c822d55a0a45f0fa994c73921701e2bb035bdaeb169c2355ed8d767414c4f73

mancha 02-03-2014 02:59 AM

I made a change to the kernel module. If you downloaded before this post, please download again and rebuild.

nox32recvmmsg.tar.bz2

S̶H̶A̶2̶5̶6̶(̶n̶o̶x̶3̶2̶r̶e̶c̶v̶m̶m̶s̶g̶.̶t̶a̶r̶.̶b̶z̶2̶)̶=̶ ̶a̶9̶7̶2̶e̶c̶3̶d̶c̶e̶a̶c̶b̶b̶5̶3̶b̶f̶d̶6̶4̶a̶f̶e̶f̶e̶0̶6̶d̶0̶e̶7̶a̶4̶8̶9̶e̶e̶5̶2̶6̶4̶b̶5̶9̶8̶a̶c̶1̶9 ̶2̶6̶6̶4̶d̶9̶f̶5̶c̶6̶e̶b̶c̶0̶

--mancha

EDIT: The module underwent one more modification after this post. Discard above hash. Latest version
should be compared to:

SHA256(nox32recvmmsg.tar.bz2)= 8c822d55a0a45f0fa994c73921701e2bb035bdaeb169c2355ed8d767414c4f73

brianL 02-03-2014 06:48 AM

Where do I put the nox32recvmmsg module, so that it's loaded permanently (survives reboot, etc) in /lib/modules/3.10.17? Which subdirectory?
EDIT
Doesn't seem to work.
Module loaded:
Code:

bash-4.2$ lsmod
Module                  Size  Used by
nox32recvmmsg          1201  1

Ran .poc:
Code:

bash-4.2$ ./slack64-14.1_CVE-2014-0038_poc
13 minutes to root
................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................ praise bob!


The Golden Rule is of no use to you whatever unless you realize it
is your move.
                -- Frank Crane

root@slackdesk:~/temp#


mancha 02-03-2014 10:55 AM

Quote:

Originally Posted by brianL (Post 5110292)
Where do I put the nox32recvmmsg module, so that it's loaded permanently (survives reboot, etc) in /lib/modules/3.10.17? Which subdirectory?

To have the module load on boot, do the following:

Code:

# mkdir -p /lib/modules/$(uname -r)/misc
# cp nox32recvmmsg.ko /lib/modules/$(uname -r)/misc
# depmod -a

Then place an insmod (or modprobe) call in /etc/rc.d/rc.local or /etc/rc.d/rc.modules. i.e.

Code:

# echo "/sbin/modprobe nox32recvmmsg" >> /etc/rc.d/rc.local
Quote:

Originally Posted by brianL
EDIT
Doesn't seem to work.

Did you try the PoC first, then load the module, then try the PoC again by chance?

To be protected you must load the module on an untainted kernel. Reboot, insmod, and you should be OK. If that doesn't work let me know.

--mancha

brianL 02-03-2014 10:57 AM

Thanks, mancha. I'll do all you suggest.

metaschima 02-03-2014 10:59 AM

It looks like it does work, because you are root at the bottom, by the # sign.

brianL 02-03-2014 11:04 AM

Quote:

Originally Posted by metaschima (Post 5110470)
It looks like it does work, because you are root at the bottom, by the # sign.

mancha's module is to prevent that happening.


All times are GMT -5. The time now is 10:59 AM.