[i]"In theory, IPv6 exists in the first place to eliminat that as a problem - Everyone can have thousands of addresses, with no risk of ever running out (strange, did the echo of that come back "640k...40k...k"?)"[/i]
Actually, with ipv6 a home user would have over 18 Quintillion addresses.
And on NT you can only take ownership, not give it. (Although you can explicitly set perms.) Actually, Microsoft changed this recently with Server 2003. Now, as long as you have full control over an object, you can change the owner to whomever you choose. With previous versions of NT you couldn't do it via explorer, but you could do it with third party tools. I suppose Microsoft finally realized the silliness of that fake limitation.
but anyone putting forth this argument must explain why IIS is hacked more than Apache. That would be a great argument if it had not stopped being true circa 2002.
Anecdotal for sure, but it's good enough for me. It's not good enough for people interested in finding the truth.
Forget the 80s. Even as recently as 1999 the net was very 'nice' place compared to what it is today. I remember finding an unpatched IIS4 server sharing the entire "c:" drive to anonymous users via ftp.
It had been sitting on the net in that spread-eagle formation for an entire year, and after inspecting the entire machine I found that nobody had touched it in all that time.
A machine in that state today would be owned within hours, or even minutes of being connected to the net.
I think the script signing feature is not designed for the scenario you're thinking of. Instead I think it's meant to help control which scripts can run inside a Windows domain.
A Windows admin can create an in-house cert authority, sign his own scripts and then configure the domain computers to trust the in-house authority. The admin can then mandate that the domain computers only run signed powershell scripts. With this in place, the admin can deploy his own config scripts to the domain computers, but users wouldn't be able to infect themselves with powershell-bases mal-ware (coming soon to a corporate network near you!), because it won't be signed.
It should be handy for the five Windows admins on the planet who understand enough to implement it.
I don't see how I was making a strawman. Individual ACL permissions are never shown unless you go digging down through several sub menus. Windows presents you with basic templates (read/modify/full control/etc) in the main screen where you edit ACLS. Sticking to those templates is sufficient for 99% of cases - much like rwx is sufficient for almost all cases in unix.
If you think the templates are too complicated, then that's your opinion. It's my experience that any type filesystem access controls are too complicated for the average user.
however I still say a program that needs to write to the root of the system drive or the Windows system folders is seriously broken, and a bad example to use to justify this feature. I agree that programs like this are seriously broken, but that's the current state of a lot of software in Windows. Hopefully UAC will cause it to improve though. As for justifying the feature, the option in question simply makes it possible to prevent users from screwing things up accidentally. Another scenario would be a document that is shared among a group of people, one of which tend to make "mistakes" with the mouse. We had a user who twice, accidentally deleted an access database on a department share. After restoring the file from our backup the second time, I removed her right to delete the file. Accidentally deleting a file is much easier than opening the file, erasing the contents, and saving it. The later would obviously be intentional, while the former has happened to almost everyone.
Isn't giving a user permission to edit files in these folders a possible security vulnerability as well? You're not giving them permission to edit other files. Just *the* file in question.
if they are allowed to edit the file, aren't they also allowed to rename it? No. If give the user the right to modify and deny the user the right to delete a file in folder that they have read-only access to, they cannot rename it either. All they can do is modify the contents.
If so, wouldn't that muck up your program just as much as if they had deleted the file outright? Just being able to modify it could theoretically muck the program up, but this is something the user is less likely to do.
Regardless, if the best example of the use of this "feature" that anyone can come up with is to work around broken and insecurely written programs, they I remain unconvinced of its general usefulness and utility. A very short perusing of your posting history tells me that you are a Linux user. One of the great strengths of UNIX is that it gives you the power to do stupid things, because taking away that power would not allow you to do clever things. Why the double-standard when Windows comes into the picture?
Yes, it was repeatable. I tried it again to verify that it was not a coincidence. The box no longer even exists and at the time I didn't report it to the OpenBSD folks.
If you want to try it it, was OpenBSD 3.5 and postfix 2.x, spamassassin and amavisd. Maybe I install it in aspare box try to repeat it and do the right thing and report it.
"it does what it's supposed to, and in my experience it *never* fails"
That was my experience too, until I accidentally typed `postsuper -r all|postfix reload` instead of `postsuper -r all;postfix reload` on my Open BSD 3.5/postfix box. It caused a Kernel panic.
Other than that, the box ran without a problem for 2.5 years straight.
Giving regular users permissions to create files in the root of the system drive or the Windows system folders is a possible privilege escalation vulnerability.
I run student several computer labs. Educational software is notorious for requiring access to files in places like the root of the filesystem or program files or the windows directory. To make these programs work, you can either give students admin permissions to the machines or find out what files the program needs access to and set permissions accordingly.
One particular program installs a file on a part of the drive that on administrators have access to. When the program launches, it writes to that file. Giving the students' account full control of that file means that they can delete it (and you'd be surprised at the inane things students will do when their minds go idle) and if they delete it, the program will not launch because they don't have the right to create files in that directory.
The solution is to give them the permission to modify but not delete the file.
a) They started programing for Windows on the 9x series, which has no security
and/or
b) They program on Windows XP while logged onto the default *admin* account, and thus, never see any securiuty issues with their programs when they test.
Hell, I have a textbook CD that installs Apache and Mysql to do the "interactive stuff" that sets up a local web server running on port 80(without checking if it is already used), uses a few hundred MB of ram (lots of page file swapping!), requires IE, not Firefox, and heaven help you if you use a Proxy server (the publisher of the sofware has never used one, or tested with it.. how many schools use proxies!) Sorry about the rant, just had to let it out... I think I know what software you're talking about. One of the permissions I had to tweak was to give users the right to create files in the root of c:\. That's a *huge* no-no (privilege escalation vulnerability). I was pissed at having to do that, but it's still slightly better than giving admin rights.:(
I manage several labs and have had to deal with this type of crap software for ages. There are better solutions than giving students admin rights and using expensive band-aides like deepfreeze.
Repackage those programs into msi installers using wininstall (or admin studio if your boss will spring for it). Set permissions on files/directories with a machine startup script using cacls and set registry permissions via group policy or the command line. You can find out where the programs are trying to write with process monitor by sysinternals.
Students in my labs log on as guests and all of the crap software they have to run works just fine. It takes a lot of work up front, but once you get a piece of software repackaged and proper permissions script worked out, you can deploy it using GPOs and never have to think about it again. Most of my labs, I have not visited in over a year.
That's what we've been doing for six years now since moving to a win2k domain. As of now we have around 40 software packages in our "softdeploy" share. Since we have multiple sites, we host the software shares on a DFS root, so we can use on policy for machines in all sites and they get their package from the local site automatically.
I convert non-msi installers into msi format with the freeware program wininstallle 2003 (which is no longer free, but I kept my copy). wininstall tends to create slightly broken packages, so I fix them by running the validation tool in Microsoft's orca utility.
If my boss would spring for a proper msi package creator like adminstudio, I wouldn't have to know so much about msi installers, but that's the way it goes.
I defended my trusty Ford below, but I have a good Honda anecdote.
We used to own a 91 Honda Accord. I really liked that car.
My wife is the typical ditsy driver - completely oblivious to any of the instruments aside from the speedometer.
She was driving the Accord about 40 miles out of town on a sweltering 105 degree day in August. I get a call from her that the car "just died". I ask her to describe the symptoms. She does and I conclude that the car probably just overheated. She then mentions, 'oh yeah, I saw the temperature gauge go way up, but I just kept driving it because I didn't want to stop'. Great.
So I get in my trusty Ford (haha), and speed over to where she is. The car stars right up by then but the temperature gauge quickly shoots up, as the radiator was completely empty. I fill up the radiator and the car starts, but I find that I can't go past third gear and have to keep the RPM about 3500 to keep the engine going. After about 40 minutes of driving we arrive at her parents house which is 20 miles away.
Upon inspection, I find that one of the spark plug boots (which extend about 6 inches into the engine block) have completely melted off and severed from the plug, and the other three boots have also melted down, and were glued to the engine block. I use needle-nose pliers and fish out as many pieces of the boots as I can, and then replace them all.
To my surprise, after that, the car ran great, but it was losing water out of the radiator at an alarming rate. We decided to buy a new car, but before doing that and friend and I took the engine out to see if there was anything we could do to salvage it. It turned out the previous owners of the car had never bothered to put anti-freeze into the radiator and as a result the engine block has been slowly eaten away by corrosion over ten years. The liquid in the radiator was being burned off almost instantly due to the heat escaping from the corroded engine block. My wife just "finished the job".
Anyhow, I guess the moral of the story is that it takes a lot of work to kill a Honda.
My '94 Ranger keeps chugging along. There are little things that are broken, but a '91 Honda accord I had a few years ago had the same little problems. I would never buy a Ford *car* though.
I'm looking at replacing my Ranger with either a Ford F150 or maybe a Toyota Tundra.
I've been using FreeBSD on my desktop for several years and would never recommend it to anyone who wanted to switch from Windows, but PC-BSD is as much a viable alternative as any of the newbie linux distros. I've also used OpenBSD, but never had a reason to try NetBSD.
Check out PC-BSD some time if you have the time. It's pretty darn slick.
Nah. Everyone knows marketshare has nothing to do with which platforms hackers target. If anything hackers would want to crack Vista just for the the notoriety./offtopic rant: To the asshole that follows me around modding all my posts down: Keep wasting your mod point shithead. I've got more Karma than you'll ever have mod-points.
Slashdot Mirror
[i]"In theory, IPv6 exists in the first place to eliminat that as a problem - Everyone can have thousands of addresses, with no risk of ever running out (strange, did the echo of that come back "640k...40k...k"?)"[/i]
Actually, with ipv6 a home user would have over 18 Quintillion addresses.
There is no chmod in Windows.
Forget the 80s. Even as recently as 1999 the net was very 'nice' place compared to what it is today. I remember finding an unpatched IIS4 server sharing the entire "c:" drive to anonymous users via ftp.
It had been sitting on the net in that spread-eagle formation for an entire year, and after inspecting the entire machine I found that nobody had touched it in all that time.
A machine in that state today would be owned within hours, or even minutes of being connected to the net.
I think the script signing feature is not designed for the scenario you're thinking of. Instead I think it's meant to help control which scripts can run inside a Windows domain.
A Windows admin can create an in-house cert authority, sign his own scripts and then configure the domain computers to trust the in-house authority. The admin can then mandate that the domain computers only run signed powershell scripts. With this in place, the admin can deploy his own config scripts to the domain computers, but users wouldn't be able to infect themselves with powershell-bases mal-ware (coming soon to a corporate network near you!), because it won't be signed.
It should be handy for the five Windows admins on the planet who understand enough to implement it.
If you think the templates are too complicated, then that's your opinion. It's my experience that any type filesystem access controls are too complicated for the average user. however I still say a program that needs to write to the root of the system drive or the Windows system folders is seriously broken, and a bad example to use to justify this feature. I agree that programs like this are seriously broken, but that's the current state of a lot of software in Windows. Hopefully UAC will cause it to improve though. As for justifying the feature, the option in question simply makes it possible to prevent users from screwing things up accidentally. Another scenario would be a document that is shared among a group of people, one of which tend to make "mistakes" with the mouse. We had a user who twice, accidentally deleted an access database on a department share. After restoring the file from our backup the second time, I removed her right to delete the file. Accidentally deleting a file is much easier than opening the file, erasing the contents, and saving it. The later would obviously be intentional, while the former has happened to almost everyone.
Yes, it was repeatable. I tried it again to verify that it was not a coincidence. The box no longer even exists and at the time I didn't report it to the OpenBSD folks.
If you want to try it it, was OpenBSD 3.5 and postfix 2.x, spamassassin and amavisd. Maybe I install it in aspare box try to repeat it and do the right thing and report it.
That was my experience too, until I accidentally typed `postsuper -r all|postfix reload` instead of `postsuper -r all;postfix reload` on my Open BSD 3.5/postfix box. It caused a Kernel panic.
Other than that, the box ran without a problem for 2.5 years straight.
Giving regular users permissions to create files in the root of the system drive or the Windows system folders is a possible privilege escalation vulnerability.
I'll give you a real world example.
I run student several computer labs. Educational software is notorious for requiring access to files in places like the root of the filesystem or program files or the windows directory. To make these programs work, you can either give students admin permissions to the machines or find out what files the program needs access to and set permissions accordingly.
One particular program installs a file on a part of the drive that on administrators have access to. When the program launches, it writes to that file. Giving the students' account full control of that file means that they can delete it (and you'd be surprised at the inane things students will do when their minds go idle) and if they delete it, the program will not launch because they don't have the right to create files in that directory.
The solution is to give them the permission to modify but not delete the file.
because...
a) They started programing for Windows on the 9x series, which has no security
and/or
b) They program on Windows XP while logged onto the default *admin* account, and thus, never see any securiuty issues with their programs when they test.
I manage several labs and have had to deal with this type of crap software for ages. There are better solutions than giving students admin rights and using expensive band-aides like deepfreeze.
Repackage those programs into msi installers using wininstall (or admin studio if your boss will spring for it). Set permissions on files/directories with a machine startup script using cacls and set registry permissions via group policy or the command line. You can find out where the programs are trying to write with process monitor by sysinternals.
Students in my labs log on as guests and all of the crap software they have to run works just fine. It takes a lot of work up front, but once you get a piece of software repackaged and proper permissions script worked out, you can deploy it using GPOs and never have to think about it again. Most of my labs, I have not visited in over a year.
That's what we've been doing for six years now since moving to a win2k domain. As of now we have around 40 software packages in our "softdeploy" share. Since we have multiple sites, we host the software shares on a DFS root, so we can use on policy for machines in all sites and they get their package from the local site automatically.
I convert non-msi installers into msi format with the freeware program wininstallle 2003 (which is no longer free, but I kept my copy). wininstall tends to create slightly broken packages, so I fix them by running the validation tool in Microsoft's orca utility.
If my boss would spring for a proper msi package creator like adminstudio, I wouldn't have to know so much about msi installers, but that's the way it goes.
I defended my trusty Ford below, but I have a good Honda anecdote.
We used to own a 91 Honda Accord. I really liked that car.
My wife is the typical ditsy driver - completely oblivious to any of the instruments aside from the speedometer.
She was driving the Accord about 40 miles out of town on a sweltering 105 degree day in August. I get a call from her that the car "just died". I ask her to describe the symptoms. She does and I conclude that the car probably just overheated. She then mentions, 'oh yeah, I saw the temperature gauge go way up, but I just kept driving it because I didn't want to stop'. Great.
So I get in my trusty Ford (haha), and speed over to where she is. The car stars right up by then but the temperature gauge quickly shoots up, as the radiator was completely empty. I fill up the radiator and the car starts, but I find that I can't go past third gear and have to keep the RPM about 3500 to keep the engine going. After about 40 minutes of driving we arrive at her parents house which is 20 miles away.
Upon inspection, I find that one of the spark plug boots (which extend about 6 inches into the engine block) have completely melted off and severed from the plug, and the other three boots have also melted down, and were glued to the engine block. I use needle-nose pliers and fish out as many pieces of the boots as I can, and then replace them all.
To my surprise, after that, the car ran great, but it was losing water out of the radiator at an alarming rate. We decided to buy a new car, but before doing that and friend and I took the engine out to see if there was anything we could do to salvage it. It turned out the previous owners of the car had never bothered to put anti-freeze into the radiator and as a result the engine block has been slowly eaten away by corrosion over ten years. The liquid in the radiator was being burned off almost instantly due to the heat escaping from the corroded engine block. My wife just "finished the job".
Anyhow, I guess the moral of the story is that it takes a lot of work to kill a Honda.
YMMV I guess.
My '94 Ranger keeps chugging along. There are little things that are broken, but a '91 Honda accord I had a few years ago had the same little problems. I would never buy a Ford *car* though.
I'm looking at replacing my Ranger with either a Ford F150 or maybe a Toyota Tundra.
I've been using FreeBSD on my desktop for several years and would never recommend it to anyone who wanted to switch from Windows, but PC-BSD is as much a viable alternative as any of the newbie linux distros. I've also used OpenBSD, but never had a reason to try NetBSD.
Check out PC-BSD some time if you have the time. It's pretty darn slick.
-Paul
Nah. Everyone knows marketshare has nothing to do with which platforms hackers target. If anything hackers would want to crack Vista just for the the notoriety. /offtopic rant: To the asshole that follows me around modding all my posts down: Keep wasting your mod point shithead. I've got more Karma than you'll ever have mod-points.