Slashdot Mirror
Serious Apache Exploit Discovered
bennyboy64 writes "An IT security company has discovered a serious exploit in Apache's HTTP web server, which could allow a remote attacker to gain complete control of a database. ZDNet reports the vulnerability exists in Apache's core mod_isapi module. By exploiting the module, an attacker could remotely gain system privileges that would compromise data security. Users of Apache 2.2.14 and earlier are advised to upgrade to Apache 2.2.15, which fixes the exploit."
Note: according to the advisory, this exploit is exclusive to Windows.
What percentage of Apache hosts run on Windows? I'd guess maybe 10%, a generous estimate. This isn't something that's going to bring the entire web down. Also, wouldn't you have to enable mod_isapi manually?
This would have been useful in the summary. From the linked page:
While I'm sure it will impact many people, I'd still imagine the majority of Apache users are running it on a platform other than Windows
Only affects Windows, though.
I wonder how many big deployments of Apache+Windows are out there.
They only have a "sense of security" anyways.
Platform. Microsoft Windows
But is this the final nail in the Apache 1.3 coffin?
Now the boss is going to be upset even when you tell them your version is not vulnerable.
7 out of the first 8 posts agree that this is Windows only.
But I don't want to restart my Windows :\
In soviet Russia, God creates you!
Perhaps the editor is worried updating his Windows servers.
http://httpd.apache.org/docs/2.0/mod/mod_isapi.html
ISAPI extension modules (.dll files) are written by third parties. The Apache Group does not author these modules, so we provide no support for them. Please contact the ISAPI's author directly if you are experiencing problems running their ISAPI extension. Please do not post such problems to Apache's lists or bug reporting pages.
MS bashing isn't really appropriate here. The module only runs on Windows (although there were some efforts to make it call out into WINE so you could run ISAPI modules on *NIX), but the vulnerability is entirely Apache's fault. It isn't doing any privilege separation or exploit mitigation, and it's running code at the highest possible privilege level, which makes this bug into a serious exploit. The same bug in a module that ran on Linux would result in a remote root exploit.
I am TheRaven on Soylent News
> The same bug in a module that ran on Linux would result in a remote root exploit.
Really?
ps -aef | grep apach
root 3029 1 0 08:10 ? 00:00:00 /usr/sbin/apache2 -k start /usr/sbin/apache2 -k start /usr/sbin/apache2 -k start
www-data 3072 3029 0 08:10 ? 00:00:00
www-data 3073 3029 0 08:10 ? 00:00:00
A Pirate and a Puritan look the same on a balance sheet.
I had to read the article to see it was Windows only . . . whew.
I scream. You scream. I assume that means we're both acquainted with the problem. We proceed.
There are many reasons why I wouldn't deploy a production (i.e. www-facing) webserver of any stripe running on Microsoft Windows, security being a big one of them.[1]
On the other hand, for some purposes (corporate intranet, for example), Apache on Windows has been a godsend--it's allowed us, for example, to migrate our internal apps to a Free platform gradually, while depreciating our existing Windows machines (and advocates) into oblivion.
---------------
1. Lots of people do, though. I'm pretty sure IBM and Oracle Websphere/Weblogic services all use Apache httpd at some level. Happy patching, boys and girls!
"Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth
Amazing; usually we're all about the M$ bashing.
Yeah, but not even Slashdot's rabid MS bashers could spin this story to be Microsoft's fault, so I guess there was no point in mentioning it.
Discussing exploits isn't "bashing".
However, in regards to MS (and we're close to being offtopic here) when was the last time you heard about an Apache vuln? Apache is relatively solid.
My problems with MS, however, are philosophical. MS seems to revel in giving the finger to standards, from the backslash to everything else. They brag about useability testing, but it almost seems like they take a group of children and mentally handicapped adults and flipping the bird to everyone else. E.g., I bought a netbook last week and tried to get on the internet with it at my favorite bar; the bar's router had something wrong with it and Windows couldn't find the DNS server. There seemed to be no way to tell Windows networking what the server address was. Meanwhile, a woman with an iPhone had no trouble using the wifi there. With earlier versions of Windows I had no trouble specifying a DNS server, and the help system is no help at all.
If I decide to run a server, it will be Apache on Linux.
I think it's funny that Apache got its neame from the earlier releases, it was a patchy server. Lots fewer patches these days!
Free Martian Whores!
PFew... for a second i was worried wether my centos VPS with tomcat (apache based, you never know), would be vulnerable to this Thanks for putting my mind at ease :)
People, what a bunch of bastards
At a place I used to work, one of my coworkers reported a simple potential security problem: the username for the admin account on all our machines is the same as the computer's name. This just eliminates one less thing for a hacker to figure out. He was accused of "snooping", whatever that means, and almost lost his job. The only thing that saved him is a higher-up with a brain.
Whenever I hear a story about a person\firm reporting security risks, I am reminded of the story of my coworker, and I have heard too many similiar stories. It has trained to me keep my mouth shut about these problems.
I would really like to make a shirt that says: "This T-shirt has a serious exploit that allows a remote attacker to gain complete control."
It should be printed around the bottom hem for maximum effect.
Could also work on tighty whiteys.
I said I'd like to make it, not wear it. :-)
Apache on linux (at least in all the setups i've seen) starts as root so it can bind port 80 but then switches down to a lower privilage user to do the actual serving. Some damage could still be done of course but hopefully it's limited compared to the damage root can do.
Apache on windows defaults to running as "localsystem" (roughly the windows equivilent of root)
You can run it as another user but apparently ( http://httpd.apache.org/docs/2.0/platform/windows.html ) that user has to have "Act as part of the operating system" privilages. MS describes said privilages as "This user right allows a process to impersonate any user without authentication. The process can therefore gain access to the same local resources as that user.".
So it seems either way to run Apache on windows you have to give it what ammounts to root privilages.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
I don't know whose fault it is but the idea of running ISS plugins under Apache on Windows scares me. Whose fault is it when you run naked through the "hot" ward snogging the e-bola patients? It's ironic that you end up getting sick because the pretty nurse you kissed had mono, but ... good lord, people...
MS bashing isn't really appropriate here.
You must either be new here or have a very short memory.
The same bug in a module that ran on Linux would result in a remote root exploit.
Apache does not normally run as root on Linux. Only on Windows.
its an irrelevant point anyways if the server is a dedicated webserver; which 99% of all websites are hosted on these days
Play on words here... Maybe its Lipstick on a pigs platform, as IIS SUCKS balls.
ISAPI == worthless in the context of using it for Apache. Most of its 'features' are well implemented in Apache with no need for ISAPI unless you're running very specialized apps that make extensive use of ISAPI.
Changing request data (URLs or headers) sent by the client # mod_rewrite .htaccess/apache.conf/conf.d
Controlling which physical file gets mapped to the URL # mod_rewrite
Controlling the user name and password used with anonymous or basic authentication #.htacess
Modifying or analyzing a request after authentication is complete # mod_rewrite
Modifying a response going back to the client #mod_rewrite
Running custom processing on "access denied" responses #mod_rewrite/mod_redirect...
Running processing when a request is complete # #/bin/bash-sh-perl-python-etc...
Run processing when a connection with the client is closed # #/bin/bash-sh-perl-python-etc...
Performing special logging or traffic analysis. # tcpdump/webalyzer
Performing custom authentication. #
Handling encryption and compression. # mod_ssl/mod_gzip
Bought the ticket, taking the ride.
You can still have undesirable security issues on dedicate web hosting servers, for three reasons. One: a remote root exploit allows the intruder to replace all of the data on your site with whatever malware/adware they feel like, or even post content to slander you. Two: they can still turn your web server into a spambot, something which is undesirable (or use it as a starting point for whatever other malicious attacks they feel like.)
thanks for pointing that out 30 minutes after the guy directly above you already had.
It doesn't matter if "its just as bad". It isn't a "root exploit". It's highly inaccurate to call it one.
Muddling terms is how you end up with nonsense like not being able to tell programs from data.
Distinctions are important for just this reason.
Yes it still sucks.
A Pirate and a Puritan look the same on a balance sheet.
Not that I'd discourage anyone from keeping their Apache up-to-date, but I decided to see what would happen if I prevented the Windows Apache on my machine from loading mod_isapi. The answer? Nothing, apparently. The only thing I really feared was that it might interfere with the Zend debugger, but no, it's fine.
Sorry, I forgot there are ads on the Web; I use Lynx.
Why would Apache run as an Administrator on Windows? Even IIS doesn't do that these days.
99% huh? Bullshit.
I would be skeptical of any claim that even a "majority" of such websites were based on Windows. For a hosting provider, the extra hardware cost AND still lower performance of Windows just isn't worth it. Toss in higher licensing fees and a "pray to the black box" method of support, and you have yourself a losing business.
Now it's true that a SLIGHT majority of *parked/empty domains* might resolve to Windows webservers. I think that's what you meant, but spinning it the way you have done is... well, incredibly dishonest of you.
A root exploit means that the attacker has complete control over the machine. It doesn't matter how important the system is or what they do with it. I just wanted to point out that an attacker who gets root over a dedicated webserver can still do undesirable things with it (in contrast to my parent poster who said that having root over a dedicated web server is no big deal). I'm not blurring distinctions
Thanks, jackass. Just what I wanted on a Monday morning: to update a half dozen Internet-facing source-based systems. Of course, it was a false alarm: submitter was too much of a toolbag to mention it was Windows-only.
(And, it being a Monday morning, I didn't initially notice the mention of mod_isapi. Of course.)
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
You can do the same sort of thing in windows. THAT the *DEFAULT* install of Apache is a admin user...
You can set who the launching user is of any service to be that of a lower user. *NOW* is the application capable of running like that? In this case probably. Many are not.
You can really really really really slice and dice how applications run on windows. In many ways it is better than the unix world. The downside is it is super super super complex. So no one uses it and just maxes out everything. In many ways the security model in windows is more interesting one (with nearly 18 different ways to control just files vs the 3 in linux).
The truth is no one really uses it and the underpinnings can be yanked out from the application because of other bad design decisions. The reason for this is that it is complex. 18 different flavors of file security vs 3. 3 is easier to remember. Even the cacls program (from xp) does not present the whole security model available. You can get at more thru the gui. The icacls program from vista and up can do more. This makes the system way more vulnerable to things as everyone just maxes it out so they do not have to fiddle with it. I cant really blame them as I do it too.
Now I did not read the article. But can you root the box if it is not running as a 'admin' type user?
But this really comes down to are you running the application as some sort of super user? Then your attack surface is at least equal to whatever that super user can do. Even in linux they know this. Hence your post of how the app trampolines itself into a lower class user. That this is not done in the windows version says something about the windows port now doesnt it?
Dumb question, but are there any Windows apps that serve pages to a browser front end that might have borrowed the Apache code in question?
The world is made by those who show up for the job.
Do you chase web hits? Who cares about Windows, moreover together with Apache httpd?
I bought a netbook last week and tried to get on the internet with it at my favorite bar; the bar's router had something wrong with it and Windows couldn't find the DNS server. There seemed to be no way to tell Windows networking what the server address was. Meanwhile, a woman with an iPhone had no trouble using the wifi there. With earlier versions of Windows I had no trouble specifying a DNS server, and the help system is no help at all.
I'm more familiar with XP (which I know you can easily specify DNS with). Was this a Windows 7 Reduced Functionality for Netbooks (TM) version? I've noticed annoying things like that on my parents' computers. The worst is that "Users and Groups" is gone in the Computer Management MMC, so those tasks have to be done via command line. Windows 7 Enterprise is better than XP (wow, remote _and_ local IP settings and outgoing/incoming rules for Firewall? finally.), but the "home" versions are crippled in ways that make security difficult.
However, in regards to MS (and we're close to being offtopic here) when was the last time you heard about an Apache vuln? Apache is relatively solid
Both Apache and IIS are pretty secure, although I have no idea why you would run Apache on a Windows server.
My problems with MS, however, are philosophical. MS seems to revel in giving the finger to standards, from the backslash to everything else.
Oh dear, you didn't just claim that the forward slash was a standard, did you? MS-DOS 1 used the same conventions as CP/M and VMS for command line arguments: forward slash. When DOS 2.0 added directories, but they had to use backslash to prevent backwards compatibility problems. They couldn't use the Apple Mac's colon separator because they already used that for drive letters, and nobody wanted to be anything like VMS's square brackets []. (See, there really was no standard)
However, they did actually implement the paths using both / and \. You could change an environment variable to set the argument prefix. Then you could happily use "cd /DOS". Even today, both symbols work. You can try:
notepad c:\autoexec.bat
notepad c:/autoexec.bat
The only time where / doesn't work is when it may be interpreted as a command line option. So "cd /Windows" doesn't work, but "cd ./Windows" does work. The point is that there was no standard for directory separators because every operating system did things their own way. And even if they did differ, there was a valid reason to do so. It was not just "giving the finger to standards". There are examples of them not using standards, like the Outlook-Exchange interface (although they probably would have had to extend the interface to get it to work using the standards so there may have been no point).
As for your DNS story, of course Windows can set the DNS manually. Don't ask me to tell you where you set it, because they keep moving around the network configuration with every version of Windows. That really pisses me off. Every upgrade of Windows since Windows for Workgroups 3.11 has made networking harder. I don't know why they have to keep fiddling!
Whoosh. The output in the posting to which you replied was demonstrating that it's not a root exploit, it's an exploit of the account 'www-data'.
On web servers I run, all executable code (apache, log rotator, etc.) is on a partition mounted readonly and nosuid. Data is on a partition mounted noexec. Nothing in the file system outside of /tmp is writable by www-data. So compromising that account gets you very little. You can't run code (except in the web server's scripting context, which doesn't get you any farther than you were when you compromised it - and doesn't get you any closer to running code as root), you can't change files. All you can hope to do is mess with the database; basically the same as what you could do if you found a hole in the site scripts.
"Patriotism is your conviction that this country is superior to all other countries because you were born in it." -- GBS
Good point! I had just assumed it was required to run php/mysql, but seems that it is only needed if you're going to run ISAPI extensions intended for IIS. I just disabled it on my WAMP servers with no side effects.
There seems to be very little need for this extension - it should be disabled by default.
The same bug in a module that ran on Linux would result in a remote root exploit.
It would not. By default apache runs as root to bind port 80 and/or 443, then it changes to an unprivileged user.
Why on earth anyone would want to run apache on windows is beyond me but it seems people do.
Muddling terms is how you end up with nonsense like not being able to tell programs from data.
But windows admins can't tell data from programs. They put both under c:\program files
I think you misread the post. They're not saying that 99% of web sites are on Windows webservers, they're saying that 99% of websites are on webservers. Full stop. Rather than home machines, or dual purposed boxes.
Of course, with that cleared up, I'm still not sure what their point is. If a webserver's running Windows, and their copy of Apache gets hit with this exploit, it's still gonna fuck some shit up.
Canada: The US's more awesome sibling.
Dedicated webservers are actually far more attractive targets to attackers, they are likely to have a lot more upstream bandwidth available to them than a typical end user making them ideal for spam, ddos, and scanning for other machines to infect, or they could merely reuse the existing webserver as a delivery mechanism for malware or phishing sites.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
Apache has to run as root at some point or else it can't bind to port 80. What you see from ps is after apache had setuid and forked. You can do the same thing in windows, but don't you agree it falls upon apache to do spawn processes as an unprivileged user? If you remember back in Apache 1 days, it was the same way in Linux, you had to run as root or load it as a plugin for inetd if you wanted to run it on port 80. I remember back in the days when we were using ipfwadm to forward all packets with server port 80 dest to port 8080 just so we could run Apache as a regular user. And even then it didn't work right all the time. In this specific case, I really don't see any reason to blame the OS.
Where is the "Ignorant" mod tag?
Wait, what? The way I read that post, it says that "99% of Apache web sites are hosted on dedicated servers." It doesn't say anything about them being Windows.
Have you tried to run anything for real with a limited user account on windows? Yeah.
I don't know that the bug doesn't exist under linux - but it wouldn't seem to. Of all the servers I run, 0% (no variance) run windows. I read this because the headline was so fearmongering only to realize ... it didn't matter.
Running software under windows these days is an experiment in running software in an unsafe, unreliable and probably infected environment anyway.
(while I'm still working with about a dozen servers, I'm mostly a computer tech - and that means spending 8+ hours a day clearing viruses off of computers with the occasional bit of repair in between).
Looks like none of the download mirrors nor the Apache's backup contain the MSI installer that includes OpenSSL. Where is it? Only the non-ssl version is available.
The only exception appears to be the filehat mirror. There is no pgp signature on apache's main server to verify its integrity either.
Was it pulled? Anyone know why it's unavailable?
Yes. It turns out things work better now than they did in 1999 when you last used Windows.
Turning to a Linux advocate for thoughts on Microsoft is like asking Hitler how he felt about the Jews.
I saw that title and said Holy Crap Now I have to go search for patches pronto! /. allowing us annoyed readers to electro-shock the submitters whenever they post such scary headlines?
Can we add a feature to
I was tempted to mod flamebait, but I had to say that Admins don't put data inside of Program Files.
Idiotic programmers put data inside of Program Files.
Admins put data in AppData, a directory in the application user's home/profile folder, where it belongs.
Boot Windows, Linux, and ESX over the network for free.
Apache doesn't run under the admin account in Windows unless you've configured it that way.
Don't take life so seriously. No one makes it out alive.
although I have no idea why you would run Apache on a Windows server.
Because sometimes you're forced to use a Windows server platform yet at the same time are under budget constraints and can't afford Microsoft's licensing models.
Apache does not run as Administrator on Windows. I'm afraid it is worse than that, it runs as LocalSystem, which is more analogous to root than Administrator is. Even if you configure the service to run as a different account, it requires the "Log on as a service" and "Act as part of the operating system" privileges. Might as well use LocalSystem.
Said, "It's just like dice but it's got more sides And it tells me who lives and who dies"
when was the last time you heard about an Apache vuln?
You don't hear about them around here, but if you go to Secunia you will see that, in the last six years, Apache vulns have been much more abundant than IIS vulns.
There is an interesting note at security focus http://www.securityfocus.com/infocus/1765 about how IIS is implemented securely by requiring kernel dll's to perform the heavy lifting. Kernel dll's, from what I understand, setup a shared state [ie. lump of memory ] between the application and the kernel for the given API.
After the foreplay is over, the application's privilege is lowered, however it still has that lump of shared memory that the kernel will rely on. It seems from the parent article about this exploit, that some jump table is being relied upon in the kernel that the app has done a poor job of cleaning up. Bad app! Worse Kernel!
Strangely, security focus seems to think this is an example of least privilege. This interface design is what has made windows so hard to lock down; and is what calls BS on the apologists. Although UNICES often have glaring holes in, for example, ioctl services, I've never seen one that was stupid as to callback into the application....
Yes he has. In his post, he even included an example: IIS.
Apache has to run as root at some point or else it can't bind to port 80.
Then don't bind to port 80. Bind to some higher port and let your firewall redirect incoming TCP port 80 traffic if you're so paranoid about this. Or run a different web server because if you're paranoid about the small window of opportunity between binding the port and dropping privileges you have larger issues.
For the lazy admins out there who are running Apache on Windows, does the mere presence of mod_isapi in the httpd.conf signal a problem or must there be other directives loading a DLL for this to be a problem?
I'm not lazy, I'm just thrifty with my time.
Amazing; usually we're all about the M$ bashing.
No kidding. Surely there's a way we can tack this on to the "Linux vulnerability" list. There's no way this can show up against Windows on the latest Secuna list we like to troll with.
Really Really Really? Well FYI, linux has access control list (acl) capabilities also, but they are not as important as they are in windows due to the better overall security.
although I have no idea why you would run Apache on a Windows server.
Because sometimes you're forced to use a Windows server platform yet at the same time are under budget constraints and can't afford Microsoft's licensing models.
Isn't that like being forced to go to work by car (rather than by bike), yet at the same time being under budget constraints and not be able to afford gasoline?
PlusFive Slashdot reader for Android. Can post comments.
What happens if they combine the exploit with a previously unknown local root vulnerability?
Many linux people seem to disregard local root vulnerabilities on machines that are single user (and they are the user) or internet servers where they are the only user that logs into them. They reason that since they don't give anyone else access to the machine, there is no reason to worry about them (i've seen lots of comments like this in the past when local root exploits are discovered).
If an exploit can give someone arbitrary code execution, even if it's in a user context, then one never knows what other things they can do. As such, you really cannot assume you haven't been rooted just because someone got access only as a given user.
If you need web hosting, you could do worse than here
Tricking a process into running your code by manipulating the stack or similar shenanigans doesn't get you privileges beyond those the process already had (leaving aside a kernel bug).
There is nothing running suid and nothing running as root once Apache drops privileges, which happens before it forks its user-facing children.
And remember, in this setup the only code you will run is code you manage to inject live into a running process. You cannot run executables from disk except those that were already installed before boot, due to the combination of ro and noexec mounts.
"Patriotism is your conviction that this country is superior to all other countries because you were born in it." -- GBS
Even if you configure the service to run as a different account, it requires the "Log on as a service" and "Act as part of the operating system" privileges
If what you wrote is true, then the Windows version of Apache is substandard and should be fixed.
What happens if they combine the exploit with a previously unknown local root vulnerability?
Why would they do that, when they could just use a previously unknown remote root vulnerability? Then they wouldn't have to jump through the additionaly hoop of the remote non-root vulnerability.
Many linux people seem to disregard local root vulnerabilities on machines that are single user
[citation needed]
You seem to have gone from an imaginary "unknown local root vulnerability" to unnamed "known local root vulnerabilities" without any indication of how you move from one to the other.. (this is beside the fact that you made the grand assertion that "many" linux people ignore them, without any backing proof at all.)
IIS, since version 6, has had fewer vulnerabilities than Apache has, however, neither have been particularly holey.
Are you seriously about the backslash? Microsoft actually WAS following the standard, the standard being CP/M.
As for your DNS problems, i've noticed on some firewalls, the IPv6 implementation seems to interfere with things on occasion. If you disable IPv6, things will work.
As for manually setting them, it works exactly the same way it always has.
If you need web hosting, you could do worse than here
.. but the vulnerability is entirely Apache's fault...
Probably not, actually. From the documentation:
Summary
This module implements the Internet Server extension API. It allows Internet Server extensions (e.g. ISAPI .dll modules) to be served by Apache for Windows, subject to the noted restrictions.
ISAPI extension modules (.dll files) are written by third parties. The Apache Group does not author these modules, so we provide no support for them. Please contact the ISAPI's author directly if you are experiencing problems running their ISAPI extension. Please do not post such problems to Apache's lists or bug reporting pages.
Emphasis theirs.
I won't join Slashcott. OTOH, If Beta goes live, I just won't be back until it's fixed. Sorry Dice.
although I have no idea why you would run Apache on a Windows server.
Because you need to run something that requires Tomcat, and all you have is Windows servers.
If you need web hosting, you could do worse than here
So I went to download the new 2.2.15 win32 binary and it appears to have been taken down? http://www.apache.org/dist/httpd/binaries/win32/ Or am I missing something?
Ahh yes, the typical "I don't like what he's saying, so i'll nitpick his argument apart then I can pretend it's not true" attack.
I was making two different points, not building upon them. But to satisfy your nit picking, I should have said "In addition" between the two points.
If you need web hosting, you could do worse than here
you must have a narrow working experience in small irrelevant shops
I'm confused. How do you execute apache if it's on a readonly and noexec partition? How about tools your server may need to exec?
You should be able to run anything in /bin.
Plus, your "leaving aside a kernel bug" seems odd, since there have been a number of such kernel bugs. The most recent was just a few days ago.
http://www.debian.com/security/2010/dsa-2005
If you need web hosting, you could do worse than here
On Solaris 10, you can avoid the need for root entirely by allowing the http user to bind to port 80.
As I said above, binaries are in the readonly partition and everything else is in the noexec partition.
Good thing we run FreeBSD.
"Patriotism is your conviction that this country is superior to all other countries because you were born in it." -- GBS
Makes it easier to migrate from IIS to Apache. Install Apache and let it use your current ISAPI modules, so your website basically works the same. Then gradually turn off each ISAPI module as you configure it the Apache way.
There are piles of ISAPI filters in use, and it's unlikely that someone going through a conversion is going to dump all of the ISAPI they paid for immediately. Or rewrite what they implemented in-house. This reduces the amount of testing and debugging that has to be done up-front, and/or allows immediate reuse of in-house code without having to 'port' it to run on Apache. Most people working on something like this will probably be Microsoft-centric, and will appreciate the ability to move gradually instead of a hard switchover, which requires a steeper learning curve.
You have a scenario of replace and regression test, instead of rebuild from scratch and run the full lot of test cases. As your renewals come up, use your projected recurring license savings to move other modules to Apache.
If you cant upgrade, simply go into \conf\apache.conf and comment out the line that loads aspi:
#LoadModule isapi_module modules/mod_isapi.so
restart apache service and you should be good to go.
And to all those people who are like 'lolz! who runs apache on windows lolz!', i would say plenty of people. Because apache is far far far far far superior to ISS. Hopefully they have done it like me and made a low privilege local user to run it. It takes a bit more work but not much.
As a potential lottery winner, I totally support tax cuts for the wealthy
Oh dear, you didn't just claim that the forward slash was a standard, did you? MS-DOS 1 used the same conventions as CP/M and VMS for command line arguments
I didn't say they were the first to not follow standards; UNIX was developed in 1969. CP/M didn't follow the standard before Windows didn't follow the standard, and so did VMS. I did read once that one of the fellows who worked on PC-DOS felt that using the forward slash as a switch was a bad idea, and his bad idea at that. IINM it was DOS 2.something that first had directories, by then it was too late to use the forward slash as a directory separator, since it was already a switch.
Don't ask me to tell you where you set it, because they keep moving around the network configuration with every version of Windows. That really pisses me off.
It's also my biggest pet peeve about Microsoft; they do this with every OS and every app.
You know what one thing that ignores standards that annoys me the most? Twist ties on bread! Screws go in clockwise, out counterclockwise. Light bulbs, machine bolts, machine nuts, EVERYTHING screws in/on clockwise, and off counterclockwise. Except bread; I think the engineer who designed the machine that twists twist ties on bread was either a former Microsoft employee or had a really twisted sense of humor.
Free Martian Whores!
I did find the settings to disable IPv6, and it was off by default (kudos to them for that). As to the backslash, it was VMS that didn't follow standard; UNIX used the slash in 1969, VMS came around six years later. I'm not sure when CP/M was frst written but I know it was later than 1969 (and probably copied the VMS model).
Free Martian Whores!
Was this a Windows 7 Reduced Functionality for Netbooks (TM) version?
Yes, and I have to wonder WTF Microsoft was thinking when they developed this. If they think I'll "upgrade" to a $200 OS to run a $200 computer they have rocks in their heads. As it is, they have me thinking "Windows 7 is the shittiest OS I ever used." (As an aside to the mods, go ahead and mod me down here, too, just like you modded my GP comment. If an honest and polite opinion is "flamebait" you must have a dog in the fight, and not have much faith in your own stuff. Glad I'm not you. Mod away, my karma is excellent).
Windows 7 Enterprise is better than XP
One would expact it to be, but then again Windows 7 professional upgrade costs more than the netbook itself (From $299.99 according to Microsoft's web site). I'll be putting Mandriva on it. Had Microsoft not given me a crippled OS I might have actually bough a copy for a homebrew desktop. As it is, I'll be sticking to Linux.
Free Martian Whores!
Kernel dll's, from what I understand, setup a shared state [ie. lump of memory ] between the application and the kernel for the given API.
I did not see any mention of shared memory between the kernel and application in the link you posted. Besides that isn't the kernel always going to have access to any application's memory, since it's the kernel?
It seems from the parent article about this exploit, that some jump table is being relied upon in the kernel that the app has done a poor job of cleaning up.
Doesn't the exploit just gain the permissions of the isapi dll? If so, and that dll cannot be run as a limited user, then Apache for Windows is inherently flawed and needs to be fixed.
Tomcat runs fine under IIS. We do it here all the time.
For a site about things like basic rights, Slashdot users sure do like to censor "dissent".
You'll also find that the IIS vulnerabilities have been much more severe. And you won't find things like time-to-patch or other issues with the patching cycle. But hey - that's another issue.
(Oh - and yes, you WILL hear about Apache vulnerabilities around here. Nice try though.)
I didn't say they were the first to not follow standards; UNIX was developed in 1969.
Are you really asserting that the first implementation of a given feature automatically defines a standard?
For that matter, was UNIX the first OS to have subdirectories? It may have been, but do you actually know this to be the case or are you just guessing?
I didn't say they were the first to not follow standards; UNIX was developed in 1969.
Why should Unix have been considered to be the standard? It was just another operating system in competition with the rest. It would have been incredibly arrogant for them at the time to tell the rest of the world that the Unix way was the only way things should be done.
How would using Apache help? The last time I checked, the Windows Server licensing model required one license per client, regardless of what software you use on the server.
Defensive much?
It works fine until you put under heavy load. Then it tends to fail. Lately it's been a memory leak. In the past it would fail to close threads and eventually reach a hard limit.
But that's not an IIS problem. People I've talked to that run that same app that we do (Blackboard) in Solaris and Linux experience the same problems.
I hate Tomcat.
According to WIkipedia, CP/M was first written in 1973. There's no guarantee that Kildall had even seen a Unix system at that point, as it was internal to AT&T.
http://en.wikipedia.org/wiki/CP/M
If you need web hosting, you could do worse than here
There never has been a standard file system path component separator.
I don't think "being first" is a very good argument for "is the standard" (not that Unix was necessarily the first operating system with a hierarchical directory structure). I would suggest that the most practical specifier of a de facto standard should be installed base. In that respect, the Windows backslash wins hands down.
Of course, the water is muddied by the fact that the URI path component separator is a normal slash.
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
Apparently, there were regressions with the build.
Here's revision 2 of Apache 2.2.15 with OpenSSL. Preliminary reports indicate that it works like it should.
Use ISO 8601 dates [YYYY-MM-DD]
Are you really asserting that the first implementation of a given feature automatically defines a standard?
No, but in many cases it should, and truthfully there weren't really very many standards back then; nearly everything was proprietary. Even later whan CP/M came around you couldn't install any CP/M on any machine like you can Linux today. But iinm the first darpanet machines ran UNIX, which should have defined the standard.
I can't be sure Unix was the first to have subdirectories, but it's the first I know of.
Free Martian Whores!
Seriously, it is that bad.
The SYSTEM account has no privileges to the network, so shared pages or a shared installation of Apache is invisible to the service. If you intend to use any network resources, the following steps should help:
Now, as far as I understand, the main IIS service runs as Local System. But, for IIS 6+, worker processes run as the user logged into the website (or a set anonymous user, if not authenticated). This seems like it could still harbor some privilege escalation exploits, but seems more secure than Apache on Windows. I guess my point is, if you run Apache for a production server, make sure it is *nix and that it is not running as root.
Said, "It's just like dice but it's got more sides And it tells me who lives and who dies"
Not that dignifying an AC with a response is a worthwhile endeavor, but my point is that Systems Admins seem to know more about the architecture of Windows than app developers do.
So, while you're busy determining the relevance of an IT shop, I'll be busy making sure that, at the very least, I can expect the same things of a third party application that Microsoft tells me I should. And when that doesn't happen, the ensuing "WTF" is well placed, at the very least.
Boot Windows, Linux, and ESX over the network for free.
As such, you really cannot assume you haven't been rooted just because someone got access only as a given user.
Well, how surprising. Isn't that why they are called "privilege escalation" vulnerabilities?
Many linux people seem to disregard local root vulnerabilities
Which only shows us that PEBKAC isn't a Windows-only problem. How true.
What is true, or at least was true up until at least Vista, is that Windows effectively only had one level of protection. Privilege escalation vulnerabilities were much, much more common on Windows systems than on Linux systems (partially because of Microsoft bugs, but mainly because of the fact that (practically) all third-party software was installed with administrative privileges and a ton of third-party software was useful for attaining privilege escalation).
Sleepy: "I think you misread the post" 2nd that. Have a coffee wake up man
I think there are a lot of web servers out there running windows and apache, especially in large organisations where ISAPI modules are needed. Windows is not something you'd use for a large shared hosting server.
The journalist should have stuck to the facts in the advisory better.
"Now it's true that a SLIGHT majority of *parked/empty domains* might resolve to Windows webservers."
Are you trying to say that 99% of servers are Linux based? This is completely untrue.
Yep, I misread this. My line reading mind wandered up to the "WINDOWS" in the subject of that post.
Sorry for being an ass.
It can help you avoid SQL Server. Shoehorning SQL Server support into common web apps is... frustrating, to say the least, and SQL Server has a habit of sucking you into an ever-growing cost spiral.