Read the bulletins.
Each security bulletin has a section in which Microsoft says whether or not the vulnerability was publicly reported, and whether or not Microsoft was aware of public exploits at the time the bulletin was published.
My understanding is that none of this month's vulnerabilities were publicly known.
Granted, you won't know how long Microsoft knew of the hole (which is useless information), but you'll know if it was a zero-day exploit (which is marginally more useful information).
Re:No matter how careful you are, you aren't enoug
on
ID Theft Made Easy
·
· Score: 1
7-11 once attempted to swipe my driver's license to buy cigarettes a few years ago.
I refused and purchased my cigarettes elsewhere, and wrote (and sent!) a letter to their corporate headquarters explaining why.
This description of the problem is flat-out wrong.
Nobody uses segments any more. Win32 programming uses a flat 32-bit address space.
The problem stems from the fact that, under the Intel architecture, procedure local variables are allocated on the stack right next to the return address pointer. If a lazy programmer allocates a 256 byte buffer and does a strcpy() that doesn't have a null within the first 256 bytes, strcpy() will keep copying data until it hits a null character, clobbering the return address (and other context information for the previous stack frame) as it does so. When the current function hits a RET instruction, the processor will jump to the overwritten return address.
DEP does nothing more than expose existing bugs. If your code triggers DEP, you already had a bug in your code... be thankful that DEP points this out to you!
You are making the mistake to believe that manufacturers will limit distribution based on current broadcast technology.
Manufacturers will sell a product wherever they see a profit to be made. If they see potential profit in selling broadcast-flag-ignoring, ATSC-capable cards through a European retailer who ships to the U.S., you can bet they'll do so.
There was little factual information about this released by the FAA.
Educated speculation is that this was most likely an application error. GetTickCount() rolls over every fifty seven days. An app that doesn't take that into consideration will go belly up when that happens. Not surprisingly, the FAA said they have problems when they leave their Windows boxes up that long.
This coincidence STRONGLY suggests that this is an application, and not an OS, issue.
Actually, that's an excellent question. And believe it or not, the answer actually kinda makes sense.
The file in question is gdiplus.dll. This file was included in Windows XP and Windows Server 2003, but was not part of previous operating systems.
Therefore, apps that used this.dll (like Internet Explorer) when installed on previous operating systems (like Windows 2000) had to ship their own copy of the.dll.
So some apps ship with their own copy, then along comes WinXP/2K3, and they add a second, system-supplied copy.
You really think firewalls belong at the perimeter?
Here's a clue: there IS NO PERIMETER any more. The internal network is often as hostile as the internet. Laptops, PDAs, unauthorized WAPs on the corporate network... the list goes on.
Anyone who belives they can secure a network be securing the perimeter is deluding themselves.
What you're really saying is, that your organization has over 400 applications that were written insecurely to begin with and were probably open to attack.
If your apps had been written from the start to use authentication, as any security-conscious design would have done, then you wouldn't have this problem.
Yet somehow it's Microsoft's fault, and Microsoft isn't secure enough.
The arguements (not necessarily yours, Marxist) just don't hold water.
Yeah, so we should curtail civil liberties for all citizens in the hopes of catching a few islamic bastards.
Let's imprison people indefinitely without charging them with a crime in case they might be terrorists. Sure, we might destroy a few innocent peoples' lives, but hey, it's all in the name of fighting terrorism, so it's okay, right?
"Michael invented and patented the world's first and only concept for non-contact UV photon induced electric field poling of ferroelectric non-linear photonic bandgap crystals,"
Say what?
Captain Kirk to the bridge, please!
The article is long on buzzwords and short on fact. Color me skeptical.
At the refinery, trucks will pull up from all the different gas companies. The trucks already have the company's additive in the tank. They all fill up with gas from the same spout at the refinery.
Actually, real traffic is hardly ever as dense as the demo. Therefore, it makes perfect sense that realworld implementations would have FAR bigger gaps between the cars, that wouldn't depend on accelleration/braking being nearly as precise.
Imagine Microsoft releasing patches any day of the week/month, with no warning. Several times a month. Imagine yourself running around to each machine patching it, sitting down, and doing it all over again when a new patch comes out.
Now imagine Microsoft adopting a policy of releasing patches on a known day of the month. Imagine coming up with a corporate plan to handle those patches on a predetermined schedule.
Actually, to a large extent, Microsoft is right here. It's no secret that as soon as a patch is released, the bad guys diff the new and old versions of the file to see what changed, which leads them right into creating an exploit.
Without the diff, it's a LOT (and I do mean a *lot*) harder for the population at large to create these attacks.
To a very large extent, there ARE no malicious attackers when the fix gets out before word of the exploit does.
I haven't RTFA, but encryption by itself is meaningless.
Where/how is the key exchange done? All the encryption in the world won't do a damned thing to protect your communications if I can easily obtain they key.
The beautiful thing about learning to program in assembly is that once you learn it on one architecture, you can almost instantly pick it up on another architecture.
I started on the 6502 and learned PIC assembly, and debugging Windows in ntsd was simple to learn from that foundation.
I check into a convention. The program has descriptions of each of the presentations with one of these barcodes. I use the barcode and my cellphone to get more info about the presentation, and decide I want to attend. Press a button on my cellphone and the convention organizers know I'm going to that session, and my cellphone calendar is updated with that session.
I'm in a museum and want to know more about the exhibit. Wave my phone over the barcode and get more info on the exhibit.
And that's just off the top of my head. Yes, I know there are other ways of accomplishing those two tasks. But imagine what could happen if all these disparate things could be integrated into my cellphone/PDA/whavever and I carry around the information I glean from my encounters with these barcodes.
Slashdot Mirror
Read the bulletins. Each security bulletin has a section in which Microsoft says whether or not the vulnerability was publicly reported, and whether or not Microsoft was aware of public exploits at the time the bulletin was published. My understanding is that none of this month's vulnerabilities were publicly known. Granted, you won't know how long Microsoft knew of the hole (which is useless information), but you'll know if it was a zero-day exploit (which is marginally more useful information).
7-11 once attempted to swipe my driver's license to buy cigarettes a few years ago.
I refused and purchased my cigarettes elsewhere, and wrote (and sent!) a letter to their corporate headquarters explaining why.
This description of the problem is flat-out wrong.
Nobody uses segments any more. Win32 programming uses a flat 32-bit address space.
The problem stems from the fact that, under the Intel architecture, procedure local variables are allocated on the stack right next to the return address pointer. If a lazy programmer allocates a 256 byte buffer and does a strcpy() that doesn't have a null within the first 256 bytes, strcpy() will keep copying data until it hits a null character, clobbering the return address (and other context information for the previous stack frame) as it does so. When the current function hits a RET instruction, the processor will jump to the overwritten return address.
DEP does nothing more than expose existing bugs. If your code triggers DEP, you already had a bug in your code... be thankful that DEP points this out to you!
You are making the mistake to believe that manufacturers will limit distribution based on current broadcast technology. Manufacturers will sell a product wherever they see a profit to be made. If they see potential profit in selling broadcast-flag-ignoring, ATSC-capable cards through a European retailer who ships to the U.S., you can bet they'll do so.
There was little factual information about this released by the FAA.
Educated speculation is that this was most likely an application error. GetTickCount() rolls over every fifty seven days. An app that doesn't take that into consideration will go belly up when that happens. Not surprisingly, the FAA said they have problems when they leave their Windows boxes up that long.
This coincidence STRONGLY suggests that this is an application, and not an OS, issue.
Don't confuse Bush's platform with conservatism. Any true conservative would immediately see that suspending due process of law is wrong.
Actually, that's an excellent question. And believe it or not, the answer actually kinda makes sense.
.dll (like Internet Explorer) when installed on previous operating systems (like Windows 2000) had to ship their own copy of the .dll.
The file in question is gdiplus.dll. This file was included in Windows XP and Windows Server 2003, but was not part of previous operating systems.
Therefore, apps that used this
So some apps ship with their own copy, then along comes WinXP/2K3, and they add a second, system-supplied copy.
Are you kidding me?
You really think firewalls belong at the perimeter?
Here's a clue: there IS NO PERIMETER any more. The internal network is often as hostile as the internet. Laptops, PDAs, unauthorized WAPs on the corporate network... the list goes on.
Anyone who belives they can secure a network be securing the perimeter is deluding themselves.
A firewall at the desktop makes a lot of sense.
You may have overflowed the buffer, but I'd bet you weren't executing code in that buffer.
That, if I understand correctly, is what DEP protects against. (Hence the acronym: data execution protection.)
What you're really saying is, that your organization has over 400 applications that were written insecurely to begin with and were probably open to attack.
If your apps had been written from the start to use authentication, as any security-conscious design would have done, then you wouldn't have this problem.
Yet somehow it's Microsoft's fault, and Microsoft isn't secure enough.
The arguements (not necessarily yours, Marxist) just don't hold water.
So you didn't read the article, your comments indicate you didn't understand the author's points, yet you're posting that he's wrong?
You're wasting bits here.
Another factor, as my marketing prof was fond of saying, is that it's very easy to lower your price.
It's very difficult to raise your price.
Yeah, so we should curtail civil liberties for all citizens in the hopes of catching a few islamic bastards.
Let's imprison people indefinitely without charging them with a crime in case they might be terrorists. Sure, we might destroy a few innocent peoples' lives, but hey, it's all in the name of fighting terrorism, so it's okay, right?
I'm a neophyte too, but my answer is that this doesn't make a hill of beans' worth of difference.
SHA wasn't "broken" at all... a brute-force attack found a single collision.
Whoop-dee-do.
Now, if it were possible to generate a message to collide with a given hash, that would be a big deal.
One collision out of 80 kilohours of CPU time isn't newsworthy, IMO.
"Michael invented and patented the world's first and only concept for non-contact UV photon induced electric field poling of ferroelectric non-linear photonic bandgap crystals,"
Say what?
Captain Kirk to the bridge, please!
The article is long on buzzwords and short on fact. Color me skeptical.
At the refinery, trucks will pull up from all the different gas companies. The trucks already have the company's additive in the tank. They all fill up with gas from the same spout at the refinery.
Copyright isn't protection of an idea. It's protection for the IMPLEMENTATION of that idea.
Which fits perfectly with the carpenter analogy.
Actually, real traffic is hardly ever as dense as the demo. Therefore, it makes perfect sense that realworld implementations would have FAR bigger gaps between the cars, that wouldn't depend on accelleration/braking being nearly as precise.
Imagine Microsoft releasing patches any day of the week/month, with no warning. Several times a month. Imagine yourself running around to each machine patching it, sitting down, and doing it all over again when a new patch comes out.
Now imagine Microsoft adopting a policy of releasing patches on a known day of the month. Imagine coming up with a corporate plan to handle those patches on a predetermined schedule.
You decide which is better.
Actually, to a large extent, Microsoft is right here. It's no secret that as soon as a patch is released, the bad guys diff the new and old versions of the file to see what changed, which leads them right into creating an exploit.
Without the diff, it's a LOT (and I do mean a *lot*) harder for the population at large to create these attacks.
To a very large extent, there ARE no malicious attackers when the fix gets out before word of the exploit does.
I haven't RTFA, but encryption by itself is meaningless. Where/how is the key exchange done? All the encryption in the world won't do a damned thing to protect your communications if I can easily obtain they key.
The beautiful thing about learning to program in assembly is that once you learn it on one architecture, you can almost instantly pick it up on another architecture.
I started on the 6502 and learned PIC assembly, and debugging Windows in ntsd was simple to learn from that foundation.
Companies can get away with this crap precisely because consumers pay for it.
When consumers stop paying for it, companies will stop producing shoddy crap.
Although I wouldn't be in the least surprise if this could be part of a lawsuit. (Hard for me to imagine it part of a criminal case, however.)
This seems seriously cool to me.
I check into a convention. The program has descriptions of each of the presentations with one of these barcodes. I use the barcode and my cellphone to get more info about the presentation, and decide I want to attend. Press a button on my cellphone and the convention organizers know I'm going to that session, and my cellphone calendar is updated with that session.
I'm in a museum and want to know more about the exhibit. Wave my phone over the barcode and get more info on the exhibit.
And that's just off the top of my head. Yes, I know there are other ways of accomplishing those two tasks. But imagine what could happen if all these disparate things could be integrated into my cellphone/PDA/whavever and I carry around the information I glean from my encounters with these barcodes.
I see a *lot* of potential here.
I despise many of the things that the ACLU fights for.
But I am also keenly aware that my freedoms in this country absolutely depend on individuals and organizations such as the ACLU fighting those fights.