Then what's the point? If everyone at the company knows this is SOP, what does a company gain from immediately terminating someone upon recieving their resignation? It's not like they're terminating you at the moment you learned you were leaving.
This looks like the same worm a friend of mine got a few weeks ago. I loaded it up in VMWare and discovered that it installed, among other things, the "FU" rootkit.
I took a rootkit class at this year's Black Hat Training from the guy who wrote FU. He pointed out that it's more of a proof-of-concept rootkit. It does allow you to hide files, registry keys and drivers from both user-mode and kernel-mode processes, but, it really doesn't go out of its way to hide itself from every possible angle, so detection (and thankfully, removal) wasn't that bad.
I was able to whip up a little app to fix it from within Windows. But had the worm's author actually expanded on FU's techniques and done a better job of hiding the rootkit, recovery would not have been as nearly as easy. (Just imagine how much fun would it be to talk a novice through Windows XP's Recovery Console!)
Once the worm authors start to get better at exploiting the potential of rootkits, we've definitely got a much better problem on our hands. The old "1. get infected, 2. run anti-virus to disinfect, 3. repeat" cycle just won't work anymore. Good luck even finding a well-implemented rootkit once it's in your kernel, let alone trying to clean it up while it's effectively able to veto every action you take.
(Yet another reason why no Windows user should run as an Administrator.)
Microsoft is introducing a User Mode Driver Framework that will allow less performance-sensitive drivers to run in user-mode. From what I've heard, video drivers and probably network drivers (especially gigabit drivers) won't be usable if run from user-mode (which is understandable). But it does look like a good start at introducing some more granularity to the way drivers are run in Windows.
The real trick here is run under a non-admin account. No matter what protections are put in place, an administrator will always have a clear shot to the kernel.
By the way, I took a class at Black Hat this year from the two authors of this book. They really know their stuff...highly recommended.
You say contract where I say gamble. If I came to your house, mowed your lawn and then demanded you pay, would you? No. Because you didn't ask for what I gave you and you'll be damned if your going to agree to my terms after the fact.
They chose their business model because it worked at the time. But now it doesn't. And just because their luck has changed doesn't mean I'm responsible for the losses from their wager.
Re:You can spot trolling ACs...
on
Deploying OpenLDAP
·
· Score: 4, Insightful
So I am to assume you would spell out common IT acronyms like Transmission Control Protocol/Internet Protocol? Or Hypertext Transfer Protocol?
I hope you never write an article about a piece of GNU software. Better start expanding that one now.
XML has become at least two things since its evolution:
an abstract structure consisting of (possibly-nested) elements and their corresponding attributes.
a human-readable representation of that structure
The interesting part of the story is that #2 came first. Since then, the W3C has recommended the Infoset abstract concept.
For the developers out there, think of how often you parse the "angle brackets" yourself. Most everyone these days (yes, I know there are exceptions) uses an API which presents elements and attributes in a wire-format-agnostic way.
As a developer, I would love to have the option to flip a switch in my code to permit Binary XML. If I can read and use the Infoset in exactly the same way, why would I object to the wire format being binary instead of text? My API is the same, but the transport is more compact and efficient.
Human-readable wire formats are great for debugging during development, but provide no real advantage in production systems (provided there are utilities available to produce human-readable XML from the binary wire format.)
Naming issues aside, the MPAA should have at least downloaded the files in question and verified their assumptions. If they're just going to go off of the filename, maybe a more appropriate way to phrase the letter would be "we suspect you are distributing our content, but if not, kindly disregard."
You really have to laugh at such a stong yet misguided threat. Do they really expect people to take them seriously?
Give the consumer the ability to purchase music in the format they want to and, most likely, they will.
I can't believe it when I think about how much money they've wasted on lawsuits, failed DRM schemes, anti-piracy lobbying, etc. These will do NOTHING to stop the problem. It's like being on an airplane that's about to go down and having some idiot running up and down the aisle yelling "buckle up!" Worthless.
Perhaphs the problem is that it is quite difficult to purchase exactly what you want.
Who do you even ask if you would like to purchase an MP3 that you just downloaded? The recording industry will tell you to go buy the whole (probably crappy) CD. Or sign up for their subscription service. Or get a DRM'ed version from iTunes.
If they want my business, they need to sell me what I want. Give me a web site where I can go and say, "hey, I just downloaded an MP3 I'd like to pay for." No subscriptions. no usernames/passwords, no contracts, no DRM. Just take my $0.99 from PayPal and we're done. Easy.
I'm always amazed at how much patchwork goes into securing the Windows desktop.
An obvious first (and large) step would be to not have every user running with Administrator privileges. Has anyone heard of any initiative by Microsoft to change this unfortunate default?
Wouldn't running your everyday apps (e.g. Outlook, IE) as a non-privileged user mitigate a lot of these worms? Some of the worms that just blast off a emails via script would be unaffected, but those that install SMTP servers and other backdoor processes would be stopped.
The current setup seems just like giving everyone a key to your house and then hiring a team of live-in security guards.
Too bad Microsoft's software features are ultimately dictated by their marketing department and not by the user community. I really feel they need to break backwards compatibility, force users (even so-called "Power Users") to use unprivileged accounts, and provide a convenient equivalent to Unix's "su".
Sure, a lot of companies would have to release updates in order to cope with use by non-administrative users, but with the current hype around security these days, I would think most companies would be willing to do so for little or no charge. Most average Joes these days have heard of viruses, worms, etc...I think it would be really bad PR for a company to say, "well, MS improved the security of Windows, and it broke our software." Most, it seems, would rather say, "MS improved the security of Windows and our software is no exception...here's the free update you need."
Given the choice of losing one customer vs. giving the game and source away for free to everyone, I can't imagine they will lose much sleep after choosing the former.
You're probably right, but I always have to keep reminding myself that the general public is much, much stupider than the Slashdot crowd...and much, much larger.
And just imagine what happens when the public gets used to this crap: the studios permanently end the sale of DVD's and slowly inch up the pricing on these self-destructing ones. There you'll have it, the pay-per-play business model they so desire.
That would also throw a fat wrench in the whole Fair Use/DVD copying argument...right now, we are entitled to make backups of our DVD's since we have purchsed them. But once you can no longer buy a DVD that will last more than 48 hours, what argument do you have that you should be allowed to back it up? Sadly, none...it's going to be gone in two days anyway.
And I'm not even going to go into the issue of the waste this system would produce. I guess the MPAA's five-year plan is to have a worthless DVD sitting next to every worthless AOL CD in every landfill across America. Someone just shoot me now.
"A copyright holder has no right to prevent someone from engaging in fair use," Durie said, noting that the studios' position would prevent students from excerpting film clips for school projects or parents making backups of their work. "That, I would suggest, can't be right. That can't be what the drafters of the DMCA intended."
Yeah. There's no way that's what they intended...what's that? The MPAA wrote what?? Ahhhhh!!!
You know what, you're right. I don't work on realtime systems. I do internal software development to automate business processes.
There's a large difference there and I think that a good developer is able to decide when to use a GC'ed environment like Java or.NET, and when to use a more low-level manual environment like C or assembly.
"Why can't I bring up this customer's account record?"
"Oh, we wrote the code in assembly. Object-oriented? Flexibility? Ability to make rapid design changes? We laugh at those things! Bwahahaha!"
I hear a lot of complaints about the lack of deterministic finalization, but I really have to wonder why people care so much about when the memory is actually freed for a particular object.
Most complaints center around the fact that you don't know when your destructor is going to execute. That's a valid concern, but there is nothing that really separates a destructor from a regular method. If you have some clean-up that needs to happen, put it into a Dispose() method and call it yourself. Pretty simple.
"But the memory isn't freed after I call Dispose()!"...who cares? Just let go of your reference and let the GC handle it. You've executed your cleanup code, so why do you care that there is a block of memory out there that you can't even see that's still allocated? It's not going to leak, so just let the GC do it's job.
The JIT compiler in the CLR generates native code as its needed. It's true, there is a delay once a new code path is executed, but following JIT compilation, the native code version is executed thereafter.
For web pages, there is a signifcant delay when a page is hit for the first time. ASP.NET needs to cache the.ASPX file in a temp folder, generate the code and then JIT it. After that, you're back to running directly from native code.
Unfortunately, the problem arises when I'm buying a product and the support contract so that at the end of twelve months I finally get the working product that I wanted in the beginning.
I'm going to have to vote in favor of Microsoft's model on this one...charge for new products, but offer service packs for free.
Unfortunately, that does nothing to address the bandwidth used by all of the unwanted email. If it still has to arrive at its destination in order to be rejected, then we've only solved part of the problem.
Of course, opening the XML file in another application would ignore formatting...just like opening a.DOC file in a hex or text editor would ignore formatting.
The issue here is the documentation of the formatting-related tags. Take the two following XML 1.0 fragments:
1:
<content>Hello! This text is <style add="italic">different</style>.</content>
2:
<content>Hello! This text is <msft secretFormattingCode="0x3B">different</msft>.</con tent>
Both are XML, both would "lose" formatting when opened in another editor, and both are probably just as easy for Office to generate. The problem is, in the absence of a published schema, the second one is much harder to understand.
MS certainly knows that their XML format will be "reverse-engineered", so I would assume they are going to make it as hard as possible to understand.
Of course, I haven't seen the actual XML format used by Office 2003, but I have to assume that if there were a nice, easy to userstand XML dialect in use, we wouldn't have all of this commotion to begin with.
Unfortunately, this doesn't work at all. I just tried (on XP) creating a folder, checking the Read Only attribute, and was still able to create a new file in the folder with no problem at all.
What you need to do is set the ACL on the folder to deny the Users group write access. I doubt the program is smart enough to change an ACL. (Programming ACL's in Win32 is not a trivial task.)
While we're on the subject, I've found this very useful:
Open up REGEDT32.EXE (on NT/2000) or REGEDIT.EXE (on XP) and change the permissions for the following keys:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\R un HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\R un
Deny the Users group both Create Subkey and Set Value. Voila, no more apps sneaking something in to run without you knowing it. Maybe do the same thing to your Startup folder under Program Files.
A Linux box running iptables will give you a very good stateful firewall for the cost of an old Pentium or Celeron box. A 300 MHz CPU, 128 mb RAM and a 1 GB HD are perfect (if not overkill!). You can probably have the whole thing running for under $80. I've done this in the past with much success for companies that would otherwise have no protection.
And don't get me wrong, this is not substandard protection. Configured properly, I consider this to be on par with a standard PIX implementation.
Slashdot Mirror
Then what's the point? If everyone at the company knows this is SOP, what does a company gain from immediately terminating someone upon recieving their resignation? It's not like they're terminating you at the moment you learned you were leaving.
Seems like a silly "security" measure to me.
This looks like the same worm a friend of mine got a few weeks ago. I loaded it up in VMWare and discovered that it installed, among other things, the "FU" rootkit.
I took a rootkit class at this year's Black Hat Training from the guy who wrote FU. He pointed out that it's more of a proof-of-concept rootkit. It does allow you to hide files, registry keys and drivers from both user-mode and kernel-mode processes, but, it really doesn't go out of its way to hide itself from every possible angle, so detection (and thankfully, removal) wasn't that bad.
I was able to whip up a little app to fix it from within Windows. But had the worm's author actually expanded on FU's techniques and done a better job of hiding the rootkit, recovery would not have been as nearly as easy. (Just imagine how much fun would it be to talk a novice through Windows XP's Recovery Console!)
Once the worm authors start to get better at exploiting the potential of rootkits, we've definitely got a much better problem on our hands. The old "1. get infected, 2. run anti-virus to disinfect, 3. repeat" cycle just won't work anymore. Good luck even finding a well-implemented rootkit once it's in your kernel, let alone trying to clean it up while it's effectively able to veto every action you take.
(Yet another reason why no Windows user should run as an Administrator.)
Microsoft is introducing a User Mode Driver Framework that will allow less performance-sensitive drivers to run in user-mode. From what I've heard, video drivers and probably network drivers (especially gigabit drivers) won't be usable if run from user-mode (which is understandable). But it does look like a good start at introducing some more granularity to the way drivers are run in Windows.
The real trick here is run under a non-admin account. No matter what protections are put in place, an administrator will always have a clear shot to the kernel.
By the way, I took a class at Black Hat this year from the two authors of this book. They really know their stuff...highly recommended.
You say contract where I say gamble. If I came to your house, mowed your lawn and then demanded you pay, would you? No. Because you didn't ask for what I gave you and you'll be damned if your going to agree to my terms after the fact.
They chose their business model because it worked at the time. But now it doesn't. And just because their luck has changed doesn't mean I'm responsible for the losses from their wager.
So I am to assume you would spell out common IT acronyms like Transmission Control Protocol/Internet Protocol? Or Hypertext Transfer Protocol?
I hope you never write an article about a piece of GNU software. Better start expanding that one now.
XML has become at least two things since its evolution:
The interesting part of the story is that #2 came first. Since then, the W3C has recommended the Infoset abstract concept.
For the developers out there, think of how often you parse the "angle brackets" yourself. Most everyone these days (yes, I know there are exceptions) uses an API which presents elements and attributes in a wire-format-agnostic way.
As a developer, I would love to have the option to flip a switch in my code to permit Binary XML. If I can read and use the Infoset in exactly the same way, why would I object to the wire format being binary instead of text? My API is the same, but the transport is more compact and efficient.
Human-readable wire formats are great for debugging during development, but provide no real advantage in production systems (provided there are utilities available to produce human-readable XML from the binary wire format.)
Windows security is hard enough to get right when you try. But it sounds like the Diebold flaws would be present regardless of their platform choice.
Even running the GEMS software on OpenBSD would do nothing to make up for their lousy secuity design.
Naming issues aside, the MPAA should have at least downloaded the files in question and verified their assumptions. If they're just going to go off of the filename, maybe a more appropriate way to phrase the letter would be "we suspect you are distributing our content, but if not, kindly disregard."
You really have to laugh at such a stong yet misguided threat. Do they really expect people to take them seriously?
Give the consumer the ability to purchase music in the format they want to and, most likely, they will.
I can't believe it when I think about how much money they've wasted on lawsuits, failed DRM schemes, anti-piracy lobbying, etc. These will do NOTHING to stop the problem. It's like being on an airplane that's about to go down and having some idiot running up and down the aisle yelling "buckle up!" Worthless.
Perhaphs the problem is that it is quite difficult to purchase exactly what you want.
Who do you even ask if you would like to purchase an MP3 that you just downloaded? The recording industry will tell you to go buy the whole (probably crappy) CD. Or sign up for their subscription service. Or get a DRM'ed version from iTunes.
If they want my business, they need to sell me what I want. Give me a web site where I can go and say, "hey, I just downloaded an MP3 I'd like to pay for." No subscriptions. no usernames/passwords, no contracts, no DRM. Just take my $0.99 from PayPal and we're done. Easy.
I'm always amazed at how much patchwork goes into securing the Windows desktop.
An obvious first (and large) step would be to not have every user running with Administrator privileges. Has anyone heard of any initiative by Microsoft to change this unfortunate default?
Wouldn't running your everyday apps (e.g. Outlook, IE) as a non-privileged user mitigate a lot of these worms? Some of the worms that just blast off a emails via script would be unaffected, but those that install SMTP servers and other backdoor processes would be stopped.
The current setup seems just like giving everyone a key to your house and then hiring a team of live-in security guards.
Too bad Microsoft's software features are ultimately dictated by their marketing department and not by the user community. I really feel they need to break backwards compatibility, force users (even so-called "Power Users") to use unprivileged accounts, and provide a convenient equivalent to Unix's "su".
Sure, a lot of companies would have to release updates in order to cope with use by non-administrative users, but with the current hype around security these days, I would think most companies would be willing to do so for little or no charge. Most average Joes these days have heard of viruses, worms, etc...I think it would be really bad PR for a company to say, "well, MS improved the security of Windows, and it broke our software." Most, it seems, would rather say, "MS improved the security of Windows and our software is no exception...here's the free update you need."
Given the choice of losing one customer vs. giving the game and source away for free to everyone, I can't imagine they will lose much sleep after choosing the former.
You're probably right, but I always have to keep reminding myself that the general public is much, much stupider than the Slashdot crowd...and much, much larger.
Excellent point.
And just imagine what happens when the public gets used to this crap: the studios permanently end the sale of DVD's and slowly inch up the pricing on these self-destructing ones. There you'll have it, the pay-per-play business model they so desire.
That would also throw a fat wrench in the whole Fair Use/DVD copying argument...right now, we are entitled to make backups of our DVD's since we have purchsed them. But once you can no longer buy a DVD that will last more than 48 hours, what argument do you have that you should be allowed to back it up? Sadly, none...it's going to be gone in two days anyway.
And I'm not even going to go into the issue of the waste this system would produce. I guess the MPAA's five-year plan is to have a worthless DVD sitting next to every worthless AOL CD in every landfill across America. Someone just shoot me now.
Just in case these greedy bastards are succesful in shutting these sites down, I give you the lyrics to "Land of A Thousand Dances", by Picket Wilson:
I said na na na na na na na na na na na na na na na. Na na na na.
Seriously, the fact that someone is able to copyright that just blows my mind.
Also, why doesn't someone just dump all of the lyrics on USENET. Then who are they going to go after?
"A copyright holder has no right to prevent someone from engaging in fair use," Durie said, noting that the studios' position would prevent students from excerpting film clips for school projects or parents making backups of their work. "That, I would suggest, can't be right. That can't be what the drafters of the DMCA intended."
Yeah. There's no way that's what they intended...what's that? The MPAA wrote what?? Ahhhhh!!!
You know what, you're right. I don't work on realtime systems. I do internal software development to automate business processes.
There's a large difference there and I think that a good developer is able to decide when to use a GC'ed environment like Java or .NET, and when to use a more low-level manual environment like C or assembly.
"Why can't I bring up this customer's account record?"
"Oh, we wrote the code in assembly. Object-oriented? Flexibility? Ability to make rapid design changes? We laugh at those things! Bwahahaha!"
Yes, the C#:
.. } ... is what I was referring to as a good alternative to finalizers/deterministic finalization.
using( someDisposableObject ) {
I hear a lot of complaints about the lack of deterministic finalization, but I really have to wonder why people care so much about when the memory is actually freed for a particular object.
Most complaints center around the fact that you don't know when your destructor is going to execute. That's a valid concern, but there is nothing that really separates a destructor from a regular method. If you have some clean-up that needs to happen, put it into a Dispose() method and call it yourself. Pretty simple.
"But the memory isn't freed after I call Dispose()!"...who cares? Just let go of your reference and let the GC handle it. You've executed your cleanup code, so why do you care that there is a block of memory out there that you can't even see that's still allocated? It's not going to leak, so just let the GC do it's job.The JIT compiler in the CLR generates native code as its needed. It's true, there is a delay once a new code path is executed, but following JIT compilation, the native code version is executed thereafter.
For web pages, there is a signifcant delay when a page is hit for the first time. ASP.NET needs to cache the .ASPX file in a temp folder, generate the code and then JIT it. After that, you're back to running directly from native code.
Unfortunately, the problem arises when I'm buying a product and the support contract so that at the end of twelve months I finally get the working product that I wanted in the beginning.
I'm going to have to vote in favor of Microsoft's model on this one...charge for new products, but offer service packs for free.
Unfortunately, that does nothing to address the bandwidth used by all of the unwanted email. If it still has to arrive at its destination in order to be rejected, then we've only solved part of the problem.
I disagree.
.DOC file in a hex or text editor would ignore formatting.
n tent>
Of course, opening the XML file in another application would ignore formatting...just like opening a
The issue here is the documentation of the formatting-related tags. Take the two following XML 1.0 fragments:
1:
<content>Hello! This text is <style add="italic">different</style>.</content>
2:
<content>Hello! This text is <msft secretFormattingCode="0x3B">different</msft>.</co
Both are XML, both would "lose" formatting when opened in another editor, and both are probably just as easy for Office to generate. The problem is, in the absence of a published schema, the second one is much harder to understand.
MS certainly knows that their XML format will be "reverse-engineered", so I would assume they are going to make it as hard as possible to understand.
Of course, I haven't seen the actual XML format used by Office 2003, but I have to assume that if there were a nice, easy to userstand XML dialect in use, we wouldn't have all of this commotion to begin with.
Unfortunately, this doesn't work at all. I just tried (on XP) creating a folder, checking the Read Only attribute, and was still able to create a new file in the folder with no problem at all.
R un R un
What you need to do is set the ACL on the folder to deny the Users group write access. I doubt the program is smart enough to change an ACL. (Programming ACL's in Win32 is not a trivial task.)
While we're on the subject, I've found this very useful:
Open up REGEDT32.EXE (on NT/2000) or REGEDIT.EXE (on XP) and change the permissions for the following keys:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\
HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\
Deny the Users group both Create Subkey and Set Value. Voila, no more apps sneaking something in to run without you knowing it. Maybe do the same thing to your Startup folder under Program Files.
A Linux box running iptables will give you a very good stateful firewall for the cost of an old Pentium or Celeron box. A 300 MHz CPU, 128 mb RAM and a 1 GB HD are perfect (if not overkill!). You can probably have the whole thing running for under $80. I've done this in the past with much success for companies that would otherwise have no protection.
And don't get me wrong, this is not substandard protection. Configured properly, I consider this to be on par with a standard PIX implementation.