You're off on the shatter vulnerability.
Microsoft's patch removed the WM_TIMER message. Also, on an unpatched box, it will not work if the application has a WM_TIMER handler, which is a trivial fix to implement in source.
Even if the application is vulnerable, making the exploit work reliably is not trivial, and is different for each version of each application. It's feasible, but a lot more difficult than you imply.
Incorrect.
You have to open permissions on a few directories and (ocassionally) files to make them writeable, but that's it. The easiest way to do this is lock up write access to everything and audit all access failures. Then log on as a normal user and play away. When something fails, view the security log as an admin and you'll see what you need to open up. After you have a list you can automate this for other systems with a cmd script and cacls.
Several years ago I ran a Windows network with several thousand users and only 5 administrative users. Everyone else was a normal user with the minimum necessary priveleges on the system. We hand tweeked file and directory permissions beyond the defaults and had everything locked up very tightly, even with applications like Office 97. I will admit that there were a few applications that gave us serious headaches (older versions of Corel Draw for example) but overall there were few issues.
There seems to be some stupid myth that a windows box requires less expertise to administer than a *nix box. Honestly, I'd say that it takes at least as much skill, if not more, to properly admin Windows. The OS is simply not as mature from a security standpoint. This is evidenced in areas like default file permissions, services, and enumeration information. All of this can be properly locked down but it requires significant knowledge to do it and can be very situationally dependent. The more recent versions of Microsoft software, however, show that this is finally sinking in and they are improving the defaults and eliminating unnecessary holes.
Set up your intranet under the assumption that it is completely exposed to the internet. Lock down the clients tight and allow users only the access they need. Never give users elevated priveleges on their local machines without sufficient justification.
Harden your internal servers with the same considerations and expose only necessary internal services. If possible, run each service on a separate system. For user accounts, use a security model that functions properly in a sizeable network environment. There are a number of choices including MS Active Directory, Novell Netware, or a combination of AFS, Kerberos, and PAM with LDAP. I cannot stress proper access control enough here. If a user doesn't need access to something, don't give it to them.
Central management is also very important. Keep your admin workstations and servers on the same network segment, and don't allow any administrative access from outside that segment. If you have to, VPN between these segments.
Now that the internal clients and servers are good, move on to the firewall/proxy setup. First, if the port/protocol is not necesarry, block it. If the protocol cannot be proxied, strongly consider blocking it, and log it if you have to let iot through. A well configured caching proxy improves security and network efficiency. Additionally, proxy logs can make a good legal hedge against liability for actions commited by your users. They also make an ideal chokepoint for web monitoring software, if necessary.
For external services, create a DMZ using an additional firewall(s). Inside the DMZ, you should use port forwarding and non-routable addresses. Don't configure DNS or allow any access into your internal network, except where absolutely necessary. Since these machines are the most vulnerable, treat them as untrusted. Use only secure protocols for connection to these systems. Generally, user accounts on these systems should be entirely different from your internal accounts.
Once you're comfortable with your configuration, you can look at deploying the IDSs. The keypoints are inside your DMZ and at your server and administration segments. Host based IDSs that take advantage of the native logging facilities are also good. Remmember though, the biggest issue with an IDS is processing the output. If you can not pick out the signal through the noise than it does you no good.
If you do that stuff, keep your patch levels up, and have decent physical security, then you are relatively safe.
Well, I know for a fact that MS hasn't released patches for Office 97 in the last year. This leaves an Office installation open to a whole slew of vulnerabilities that could easily allow system compromise. They also don't provide support anymore for 97 or below. I can't say anything particular about Win 95 because from a security perspective I just assume it's compromised. In general the pressure is never direct. It's just that if you run older versions of MS software you accept that you will remain unprotected against known vulnerabilities and you will get no support from Microsoft.
In the mid 90's when the mainstream Internet boom was spinning up Microsoft started something called the Windows Open Standard Architecture (WOSA). This included several varied initiatives such as multiplatform MFC (Unixes and Mac) and the Microsoft Messaging API (MAPI). This initiative was a major marketing point for Microsoft and played a big part in reeling in customers with the promise of platform independence.
Unfortunately this story doesn't have a happy ending. Microsoft dangled the cross platform carrot and stalled on the actual implementation until until long after the majority of the market had been hooked. They failed to deliver on many of their most important promises, including such early ones as a cross platform Exchange client and Office applications.
This isn't to say that the.NET architecture is a bad thing. In fact, I'm really impressed with a lot of what I've seen so far. But I'd still be very careful how far I let Microsoft lead me down any road.
I almost forgot one of the really important points for Intel. Hyperthreading allows the processor to take much better advantage of the bandwidth of RDRAM, given RDRAM's memory latency. The two technologies complement each other very nicely, but once again RDRAM is another relatively pricey technology.
The main idea, though, is that you get more bang for your buck through better use of an existing processor. A 10% - 30% increase in processing power for a 5% increase in cost is pretty good math. Intel's prices may be high for the CPU's, but the technology is viable and it's only a matter of time before other CPU manufacturers start using it.
That also hits the people who are using the gateway as a firewall between them and the Internet. After all, the vast majority broadband cable providers afford no guarantee of security in any form.
Re:Configuration and scripting
on
Apache 2.0 vs. IIS
·
· Score: 2, Interesting
I wouldn't say it's hidden, but it's not very openly presented either. I never really found the MSDN of as much use in my scripting days as the resource kit. You pretty much have to plunk down the $80(?) for the resource kit to get started, but that's a one time purchase and definately worth it. Along with that you'll probably need a few books on scripting; I mentioned in another post that I liked the New Riders series. Other than that the majority of the scripting resources are built in to the OS or free.
I agree that these things should be more accessable. For instance, paying for the resource kit is absurd when really it's just a set beta utilities and things that should have been included. Also, there's no excuse why there is no scripting and almost no command line requirements at all for an MCSE. So, yes, it's a very frustrating thing to encounter. Especially when you come from a Unix background.
Standard NT Command Shell, Windows Scripting Host, Kix scripting, and Active State's PERL and Python implementations are some major ones. I generally tried to use the straight NT command shell and a few additional resource kit utilities whenever possible. That approach was guaranteed to work on plain vanilla NT. This was a few years ago, though. you can probably assume now that all machines have scripting host installed on them at the least. The best books I ever had on the subject were published by New Riders. As I remember they published Titles on NT cmd shell, scripting host, and automated deployment. I've noticed several other books on NT/2K/XP scripting popping up in the book stores but I don't admin NT anymore so I don't really know the quality of them.
These days I work in computer security. Now if anyone wants to point out the most serious failing of the MS approach I'd say that's it. Too much point, click it works and not enough "Why" and what is the impact of this. That's where we have infinitely more headaches than with the Unixen.
Re:Configuration and scripting
on
Apache 2.0 vs. IIS
·
· Score: 4, Informative
Hate to tell you this, but in NT/2K you can script essentially everything. It's pretty much always been that way. The problem is that NT admins rarely ever learn it because everything appears so GUI centric. The GUI interface is very approachable to the novice. In the long run, though, you can only go so far with the training wheels on and to properly administer an MS system/network you have to learn how the OS actually works. Unfortunately that's not covered by the MCSE requirements.
I spent 3 years as an NT admin and I can honestly state that I scripted any repetitious or large tasks I encountered. Of course most of the other admins I worked with, while fairly technically knowledgeable, seemed oblivious to the concept of scripting or programming in general. I'm not a fan of Microsoft (I don't like signing 12 NDA's to look at my OS's source) and NT/2K/XP do have some serious flaws. But it get's a bad rap for the wrong reason most of the time, and a lack of scripting support is not really one of it's failings.
I hate to sound harsh but I think you might be looking at this from the wrong angle. The truth is that many of these aid organizations do more harm than good in the long run. They try to solve the problem by providing a little additional food for subsistence and medicines for the most common diseases. This may give people a warm fuzzy, but all it really does is add to the problem of over-taxed resources and over-population in these regions.
If I were you I'd look into organizations whose primary focus is infrastructure development. Building schools, developing industry, and raising the general standard of living is a far more effective goal. It may not have the same immediate gratification of medical aide, but in the long run it's a lot better for the people and probably more along the lines of your skills.
Scaling the size isn't really the issue. Given current OLED technolology and average use you wouldn't get even a year of service out of a monitor or television display before the OLED layer started to break down and signifcantly damage picture quality. With cell phones and camcorders the display isn't active anywhere near as much as on a TV or monitor so they are being tested in these applications first. Once they get the lifespan issues resolved, though, OLED's will no doubt be a viable alternative to other display technology.
Not to be nitpicky, but the article stated that this is one of the major obstacles to bringing the LCD into the consumer television market. In that case it's fixed resolution anyway, so that's not a real drawback. I agree with you, though, that that fixed resolution is an obstacle for PC's.
Why stop with encryption? I'm also extremely disturbed that no one is interviewing the airlines with similar questions. I mean, shouldn't we be asking if they feel guilty about creating a vehicle that could so easily be used as such a powerful weapon? Didn't they realize the dangers they were creating? Doesn't this make us question the very foundation of the entire air travel industry? Shouldn't air travel be tightly regulated by the government and not placed in the hands of any potential terrorist?
I hope that wasn't too sarcastic, but I really do believe that you can't uncork a bottle. Right now people just need targets for their anger and grief, and unfortunately this is an easy one. Regulation and accountability are important, but in this case it almost doesn't even apply. Any attempt to really try to regulate and control encryption would, at this point, just leave strong encryption in the hands of criminals. Knee jerk reactions are not the proper response. They may seem like a quick fix but in the long run they'll do more harm than good.
I have a WAP phone (Mitsubishi T250) that I use pretty regularly. I'm not a fan of the phone itself but I get a lot of use out of the wireless internet features. Mainly it's just a big convienence for getting things like phone numbers, addresses, directions, movie showtimes, email, etc. when I'm out. I know there are voice based services for most of the things I use it for, but if I'm doing something like searching through theaters and showtimes I find the WAP approach much easier to navigate and it doesn't use my cell minutes.
Still, I'll probably be switching to a regular cell phone in the near future just because I've found the Mitsubishi to be such a poor quality phone, and I haven't found any WAP phones that I like.
At $60 (100 - rebate) the Linksys includes a 4 port 10/100 switch. I bought one for my parents and set it up and they love it. For them it's an ideal solution because it covers everything they need and it's simple. For the original poster though, I think that it would fall short. AFAIK all of these devices can do static IP and DHCP at the same time. I don't think any of them will do anything more complicated than port forwarding and a single DMZ host (both internal and external though, not a true DMZ).
Most edutainment is really pretty boring, but this seems like a good conceptI think I've heard of something similar based on Z80 processors. Are there many other projects like this (especially for other languages)?
Do you have any idea how strict the regulations are regarding intelligence collection and dissemination? Do a little research and you'll find out that someone working for the government can go to jail for a very long time for collecting information illegally. The laws don't leave much gray area there. How about doing a little honest fact checking and not spreading rumors and propaganda. If you're genuinely curious fas.org has useful information and for further clarification there's always Freedom of Information Act requests.
This whole scare over Carnivore and other related issues is just uninformed noise. Monitoring email or wireless traffic is no different than authorized telephone wire taps. They are a necesarry tool for law enforcement, and I consider them completely acceptable as long as there is proper discretion and judgement applied to their use, and a reasonable set of checks and balances exists. Law enforcement and intelligence agencies operate within the bounds of our laws; if they violate these laws there are severe forms of reprimand. Given that, would be more dangerous not to allow them the tools necesarry to do their jobs.
Re:Isn't this a cartoon already?
on
The New Zelda
·
· Score: 1
Zelda 2: The Adventures of Link was supposed to be more realistic in style, but really it was just a terrible game. The rest of them had a much more cartoon style, though. That really struck me as part of the appeal, and part of why 2 was so bad.
There is validity to what you wrote, but you shouldn't ignore the fact that drug companies primary goal is to make money; sometimes that conflicts with the more altruistic goal of curing disease.
Case in point:
In the early 1980's long term studies were completed that linked the cause of many ulcers to bacterial infections. At this time several drug companies were making a hefty profit on expensive anti-ulcer medication. Now these are the kind of drugs that a patient had to take pretty much for the rest of his or her life, so that's a continuing source of revenue. The results of the study were published but went pretty much nowhere for about a decade. Doctors recieve a lot of their information on treatments and procedures from drug company reps. The drug companies ignored or buried the information because that would mean trading a high paying life time customer for a two week dose of cheap antibiotics. Eventually the information on bacterial causes of cancer did make it to the public, but should it really have taken ten years?
Slashdot Mirror
You're off on the shatter vulnerability.
Microsoft's patch removed the WM_TIMER message. Also, on an unpatched box, it will not work if the application has a WM_TIMER handler, which is a trivial fix to implement in source.
Even if the application is vulnerable, making the exploit work reliably is not trivial, and is different for each version of each application. It's feasible, but a lot more difficult than you imply.
Incorrect.
You have to open permissions on a few directories and (ocassionally) files to make them writeable, but that's it. The easiest way to do this is lock up write access to everything and audit all access failures. Then log on as a normal user and play away. When something fails, view the security log as an admin and you'll see what you need to open up. After you have a list you can automate this for other systems with a cmd script and cacls.
Several years ago I ran a Windows network with several thousand users and only 5 administrative users. Everyone else was a normal user with the minimum necessary priveleges on the system. We hand tweeked file and directory permissions beyond the defaults and had everything locked up very tightly, even with applications like Office 97. I will admit that there were a few applications that gave us serious headaches (older versions of Corel Draw for example) but overall there were few issues.
There seems to be some stupid myth that a windows box requires less expertise to administer than a *nix box. Honestly, I'd say that it takes at least as much skill, if not more, to properly admin Windows. The OS is simply not as mature from a security standpoint. This is evidenced in areas like default file permissions, services, and enumeration information. All of this can be properly locked down but it requires significant knowledge to do it and can be very situationally dependent. The more recent versions of Microsoft software, however, show that this is finally sinking in and they are improving the defaults and eliminating unnecessary holes.
Set up your intranet under the assumption that it is completely exposed to the internet. Lock down the clients tight and allow users only the access they need. Never give users elevated priveleges on their local machines without sufficient justification.
Harden your internal servers with the same considerations and expose only necessary internal services. If possible, run each service on a separate system. For user accounts, use a security model that functions properly in a sizeable network environment. There are a number of choices including MS Active Directory, Novell Netware, or a combination of AFS, Kerberos, and PAM with LDAP. I cannot stress proper access control enough here. If a user doesn't need access to something, don't give it to them.
Central management is also very important. Keep your admin workstations and servers on the same network segment, and don't allow any administrative access from outside that segment. If you have to, VPN between these segments.
Now that the internal clients and servers are good, move on to the firewall/proxy setup. First, if the port/protocol is not necesarry, block it. If the protocol cannot be proxied, strongly consider blocking it, and log it if you have to let iot through. A well configured caching proxy improves security and network efficiency. Additionally, proxy logs can make a good legal hedge against liability for actions commited by your users. They also make an ideal chokepoint for web monitoring software, if necessary.
For external services, create a DMZ using an additional firewall(s). Inside the DMZ, you should use port forwarding and non-routable addresses. Don't configure DNS or allow any access into your internal network, except where absolutely necessary. Since these machines are the most vulnerable, treat them as untrusted. Use only secure protocols for connection to these systems. Generally, user accounts on these systems should be entirely different from your internal accounts.
Once you're comfortable with your configuration, you can look at deploying the IDSs. The keypoints are inside your DMZ and at your server and administration segments. Host based IDSs that take advantage of the native logging facilities are also good. Remmember though, the biggest issue with an IDS is processing the output. If you can not pick out the signal through the noise than it does you no good.
If you do that stuff, keep your patch levels up, and have decent physical security, then you are relatively safe.
Same for me.
Well, I know for a fact that MS hasn't released patches for Office 97 in the last year. This leaves an Office installation open to a whole slew of vulnerabilities that could easily allow system compromise. They also don't provide support anymore for 97 or below. I can't say anything particular about Win 95 because from a security perspective I just assume it's compromised.
In general the pressure is never direct. It's just that if you run older versions of MS software you accept that you will remain unprotected against known vulnerabilities and you will get no support from Microsoft.
Not that I agree with the assessment but if you're shooting for comparisons on Camino I'd say they reminded me of the aliens from the Abyss.
In the mid 90's when the mainstream Internet boom was spinning up Microsoft started something called the Windows Open Standard Architecture (WOSA). This included several varied initiatives such as multiplatform MFC (Unixes and Mac) and the Microsoft Messaging API (MAPI). This initiative was a major marketing point for Microsoft and played a big part in reeling in customers with the promise of platform independence. .NET architecture is a bad thing. In fact, I'm really impressed with a lot of what I've seen so far. But I'd still be very careful how far I let Microsoft lead me down any road.
Unfortunately this story doesn't have a happy ending. Microsoft dangled the cross platform carrot and stalled on the actual implementation until until long after the majority of the market had been hooked. They failed to deliver on many of their most important promises, including such early ones as a cross platform Exchange client and Office applications.
This isn't to say that the
I almost forgot one of the really important points for Intel. Hyperthreading allows the processor to take much better advantage of the bandwidth of RDRAM, given RDRAM's memory latency. The two technologies complement each other very nicely, but once again RDRAM is another relatively pricey technology.
The main idea, though, is that you get more bang for your buck through better use of an existing processor. A 10% - 30% increase in processing power for a 5% increase in cost is pretty good math. Intel's prices may be high for the CPU's, but the technology is viable and it's only a matter of time before other CPU manufacturers start using it.
That also hits the people who are using the gateway as a firewall between them and the Internet. After all, the vast majority broadband cable providers afford no guarantee of security in any form.
I wouldn't say it's hidden, but it's not very openly presented either. I never really found the MSDN of as much use in my scripting days as the resource kit. You pretty much have to plunk down the $80(?) for the resource kit to get started, but that's a one time purchase and definately worth it. Along with that you'll probably need a few books on scripting; I mentioned in another post that I liked the New Riders series. Other than that the majority of the scripting resources are built in to the OS or free.
I agree that these things should be more accessable. For instance, paying for the resource kit is absurd when really it's just a set beta utilities and things that should have been included. Also, there's no excuse why there is no scripting and almost no command line requirements at all for an MCSE. So, yes, it's a very frustrating thing to encounter. Especially when you come from a Unix background.
Standard NT Command Shell, Windows Scripting Host, Kix scripting, and Active State's PERL and Python implementations are some major ones. I generally tried to use the straight NT command shell and a few additional resource kit utilities whenever possible. That approach was guaranteed to work on plain vanilla NT. This was a few years ago, though. you can probably assume now that all machines have scripting host installed on them at the least. The best books I ever had on the subject were published by New Riders. As I remember they published Titles on NT cmd shell, scripting host, and automated deployment. I've noticed several other books on NT/2K/XP scripting popping up in the book stores but I don't admin NT anymore so I don't really know the quality of them.
These days I work in computer security. Now if anyone wants to point out the most serious failing of the MS approach I'd say that's it. Too much point, click it works and not enough "Why" and what is the impact of this. That's where we have infinitely more headaches than with the Unixen.
Hate to tell you this, but in NT/2K you can script essentially everything. It's pretty much always been that way. The problem is that NT admins rarely ever learn it because everything appears so GUI centric. The GUI interface is very approachable to the novice. In the long run, though, you can only go so far with the training wheels on and to properly administer an MS system/network you have to learn how the OS actually works. Unfortunately that's not covered by the MCSE requirements.
I spent 3 years as an NT admin and I can honestly state that I scripted any repetitious or large tasks I encountered. Of course most of the other admins I worked with, while fairly technically knowledgeable, seemed oblivious to the concept of scripting or programming in general. I'm not a fan of Microsoft (I don't like signing 12 NDA's to look at my OS's source) and NT/2K/XP do have some serious flaws. But it get's a bad rap for the wrong reason most of the time, and a lack of scripting support is not really one of it's failings.
If I were you I'd look into organizations whose primary focus is infrastructure development. Building schools, developing industry, and raising the general standard of living is a far more effective goal. It may not have the same immediate gratification of medical aide, but in the long run it's a lot better for the people and probably more along the lines of your skills.
Scaling the size isn't really the issue. Given current OLED technolology and average use you wouldn't get even a year of service out of a monitor or television display before the OLED layer started to break down and signifcantly damage picture quality. With cell phones and camcorders the display isn't active anywhere near as much as on a TV or monitor so they are being tested in these applications first. Once they get the lifespan issues resolved, though, OLED's will no doubt be a viable alternative to other display technology.
Not to be nitpicky, but the article stated that this is one of the major obstacles to bringing the LCD into the consumer television market. In that case it's fixed resolution anyway, so that's not a real drawback. I agree with you, though, that that fixed resolution is an obstacle for PC's.
Why stop with encryption? I'm also extremely disturbed that no one is interviewing the airlines with similar questions. I mean, shouldn't we be asking if they feel guilty about creating a vehicle that could so easily be used as such a powerful weapon? Didn't they realize the dangers they were creating? Doesn't this make us question the very foundation of the entire air travel industry? Shouldn't air travel be tightly regulated by the government and not placed in the hands of any potential terrorist?
I hope that wasn't too sarcastic, but I really do believe that you can't uncork a bottle. Right now people just need targets for their anger and grief, and unfortunately this is an easy one. Regulation and accountability are important, but in this case it almost doesn't even apply. Any attempt to really try to regulate and control encryption would, at this point, just leave strong encryption in the hands of criminals. Knee jerk reactions are not the proper response. They may seem like a quick fix but in the long run they'll do more harm than good.
I have a WAP phone (Mitsubishi T250) that I use pretty regularly. I'm not a fan of the phone itself but I get a lot of use out of the wireless internet features. Mainly it's just a big convienence for getting things like phone numbers, addresses, directions, movie showtimes, email, etc. when I'm out. I know there are voice based services for most of the things I use it for, but if I'm doing something like searching through theaters and showtimes I find the WAP approach much easier to navigate and it doesn't use my cell minutes.
Still, I'll probably be switching to a regular cell phone in the near future just because I've found the Mitsubishi to be such a poor quality phone, and I haven't found any WAP phones that I like.
At $60 (100 - rebate) the Linksys includes a 4 port 10/100 switch. I bought one for my parents and set it up and they love it. For them it's an ideal solution because it covers everything they need and it's simple. For the original poster though, I think that it would fall short. AFAIK all of these devices can do static IP and DHCP at the same time. I don't think any of them will do anything more complicated than port forwarding and a single DMZ host (both internal and external though, not a true DMZ).
Most edutainment is really pretty boring, but this seems like a good conceptI think I've heard of something similar based on Z80 processors. Are there many other projects like this (especially for other languages)?
Do you have any idea how strict the regulations are regarding intelligence collection and dissemination? Do a little research and you'll find out that someone working for the government can go to jail for a very long time for collecting information illegally. The laws don't leave much gray area there. How about doing a little honest fact checking and not spreading rumors and propaganda. If you're genuinely curious fas.org has useful information and for further clarification there's always Freedom of Information Act requests.
This whole scare over Carnivore and other related issues is just uninformed noise. Monitoring email or wireless traffic is no different than authorized telephone wire taps. They are a necesarry tool for law enforcement, and I consider them completely acceptable as long as there is proper discretion and judgement applied to their use, and a reasonable set of checks and balances exists. Law enforcement and intelligence agencies operate within the bounds of our laws; if they violate these laws there are severe forms of reprimand. Given that, would be more dangerous not to allow them the tools necesarry to do their jobs.
Zelda 2: The Adventures of Link was supposed to be more realistic in style, but really it was just a terrible game. The rest of them had a much more cartoon style, though. That really struck me as part of the appeal, and part of why 2 was so bad.
They've been big on home and car stereos for a while. It's just a backlit LCD that 'appears' to have depth. Pretty mundane actually.
There is validity to what you wrote, but you shouldn't ignore the fact that drug companies primary goal is to make money; sometimes that conflicts with the more altruistic goal of curing disease.
Case in point:
In the early 1980's long term studies were completed that linked the cause of many ulcers to bacterial infections. At this time several drug companies were making a hefty profit on expensive anti-ulcer medication. Now these are the kind of drugs that a patient had to take pretty much for the rest of his or her life, so that's a continuing source of revenue. The results of the study were published but went pretty much nowhere for about a decade. Doctors recieve a lot of their information on treatments and procedures from drug company reps. The drug companies ignored or buried the information because that would mean trading a high paying life time customer for a two week dose of cheap antibiotics. Eventually the information on bacterial causes of cancer did make it to the public, but should it really have taken ten years?
Just a thought.