Slashdot Mirror
Domain: securityfocus.com
Stories and comments across the archive that link to securityfocus.com.
Comments · 2,651
-
Re:Where's the evidence???
Odd that absolutely none of them mention that debug privlidges are required...
This one and this one are both the same vuln. Read the discussion page for 9694 or see http://www.securityfocus.com/archive/1/354392 for a better description. And I quote: It should be noted that a local user would require the SeDebugPrivilege to exploit these issues.No, I'd say 1 can be considered a DoS, the rest are privlidge escalation.
Read the descriptions more carefully.
This one causes a memory leak; DoS.
This one is possible information disclosure, not code execution.
This is another memory leak; a DoS.I have to disagree. There are some inherent problems with the NT design. Sure, most problems are implimentation issues, but there are certainly several design flaws as well.
Design flaws like what? Give me exmples. Every object from window, to thread to registry key has a seperate ACL. API interfaces are divided into subsystems that all have to use the same system interface. All system calls go through ntdll.dll. All strings use a single format and are sized. NT uses memory protection like any other modern PC OS. All named objects are stored in the object manager. Services like the IO manager use layers to abstract functions.I can't agree with that. If something must be run in kernel mode, it should be considered part of the kernel.
*sigh* There is really no point to argue the definition of a kernel. You are right though, if a vuln exists in something with the privledges of the kernel, it might as well be part of the kernel from a security standpoint. I think the discussion originally made the statement that no vulns exist in the kernel itself (ntoskrnl.exe); not including optional modules. You found some. The difference is that you can choose to not use optional modules, you can't choose to not use the kernel.
As for things that must be run in the kernel, a mircokernel architecture should have almost nothing. MS traded safety for less overhead by moving so much into kernel mode. I agree that there is too much. Ideally the user should be able to choose what they want to have where. However, MS has never been one for giving users choices.There are many many more that I could have gone through and listed...
Bring 'em on! -
Re:Where's the evidence???
Odd that absolutely none of them mention that debug privlidges are required...
This one and this one are both the same vuln. Read the discussion page for 9694 or see http://www.securityfocus.com/archive/1/354392 for a better description. And I quote: It should be noted that a local user would require the SeDebugPrivilege to exploit these issues.No, I'd say 1 can be considered a DoS, the rest are privlidge escalation.
Read the descriptions more carefully.
This one causes a memory leak; DoS.
This one is possible information disclosure, not code execution.
This is another memory leak; a DoS.I have to disagree. There are some inherent problems with the NT design. Sure, most problems are implimentation issues, but there are certainly several design flaws as well.
Design flaws like what? Give me exmples. Every object from window, to thread to registry key has a seperate ACL. API interfaces are divided into subsystems that all have to use the same system interface. All system calls go through ntdll.dll. All strings use a single format and are sized. NT uses memory protection like any other modern PC OS. All named objects are stored in the object manager. Services like the IO manager use layers to abstract functions.I can't agree with that. If something must be run in kernel mode, it should be considered part of the kernel.
*sigh* There is really no point to argue the definition of a kernel. You are right though, if a vuln exists in something with the privledges of the kernel, it might as well be part of the kernel from a security standpoint. I think the discussion originally made the statement that no vulns exist in the kernel itself (ntoskrnl.exe); not including optional modules. You found some. The difference is that you can choose to not use optional modules, you can't choose to not use the kernel.
As for things that must be run in the kernel, a mircokernel architecture should have almost nothing. MS traded safety for less overhead by moving so much into kernel mode. I agree that there is too much. Ideally the user should be able to choose what they want to have where. However, MS has never been one for giving users choices.There are many many more that I could have gone through and listed...
Bring 'em on! -
Re:Where's the evidence???First, as pedantic as it may sound, the kernel itself is very much seperate than other things that run in kernel mode. Kernel mode drivers are just DLLs.
How about the 'Client Server Run-time Subsystem'?
Otherwise known as the win32 server. Yes, since NT4 most of it moved into kernel mode (win32k.sys) to reduce overhead. Before that, it was all in csrss.exe and csrsrv.dll, both entirely user-mode.How about Netbios?
netbios.sys does run in kernel mode; it's a network protocol driver. Is it so bad to have a protocol driver in kernel mode?How about the Virtual DOS Machine (VDM)?
Most of that runs in ntvdm.exe with some kernel support so it can use v86 mode. Surely you want CPU protect mode control in the kernel?The program iexplore.exe is run in userspace, but the majority of the functions of the browser are not in the program, but in the OS itself. It is certainly not a solely user-space program.
Yes it is. It is integrated with the Windows shell, but not anything in kernel mode. It depends on what you mean by operating system. Most of IE's code is in shell32.dll, mshtml.dll, shdocvw.dll, ole32.dll and browseui.dll; all of which run exclusively in user mode.The fact that Windows system security is crap should not be used to disregard the Windows Kernel problems, after all, it's the kernel that this thread is all about.
The Windows NT security model is designed quite well; MS's security problems are in their poor implementation. Here is a good post about the difference.First off, I listed FOUR, count 'em, 4 exploits that affect XP. Second, I clearly said, in no uncertain terms, that this was a quickly-compiled, partial list. I listed less than half the Microsoft kernel exploits my quick search found.
Several of them go to the same vuln; the one that requires the debug priveledge that normally only admins have anway.
This one is in CSR not the kernel.
This one is in the mup.sys driver, not the kernel.
This one is a DOS attack in the netbios driver, not the kernel.
This is an uninitialized disclosure of data that would be extremely unpredictable to get anything out of.
This is a serious hole.
The others are at best DOS attacks, not even priveledge escilations. Yes, Microsoft runs too many things in kernel mode, but the kernel itself isn't as vulnerable as you claim. And certainly not by design. -
Re:Where's the evidence???First, as pedantic as it may sound, the kernel itself is very much seperate than other things that run in kernel mode. Kernel mode drivers are just DLLs.
How about the 'Client Server Run-time Subsystem'?
Otherwise known as the win32 server. Yes, since NT4 most of it moved into kernel mode (win32k.sys) to reduce overhead. Before that, it was all in csrss.exe and csrsrv.dll, both entirely user-mode.How about Netbios?
netbios.sys does run in kernel mode; it's a network protocol driver. Is it so bad to have a protocol driver in kernel mode?How about the Virtual DOS Machine (VDM)?
Most of that runs in ntvdm.exe with some kernel support so it can use v86 mode. Surely you want CPU protect mode control in the kernel?The program iexplore.exe is run in userspace, but the majority of the functions of the browser are not in the program, but in the OS itself. It is certainly not a solely user-space program.
Yes it is. It is integrated with the Windows shell, but not anything in kernel mode. It depends on what you mean by operating system. Most of IE's code is in shell32.dll, mshtml.dll, shdocvw.dll, ole32.dll and browseui.dll; all of which run exclusively in user mode.The fact that Windows system security is crap should not be used to disregard the Windows Kernel problems, after all, it's the kernel that this thread is all about.
The Windows NT security model is designed quite well; MS's security problems are in their poor implementation. Here is a good post about the difference.First off, I listed FOUR, count 'em, 4 exploits that affect XP. Second, I clearly said, in no uncertain terms, that this was a quickly-compiled, partial list. I listed less than half the Microsoft kernel exploits my quick search found.
Several of them go to the same vuln; the one that requires the debug priveledge that normally only admins have anway.
This one is in CSR not the kernel.
This one is in the mup.sys driver, not the kernel.
This one is a DOS attack in the netbios driver, not the kernel.
This is an uninitialized disclosure of data that would be extremely unpredictable to get anything out of.
This is a serious hole.
The others are at best DOS attacks, not even priveledge escilations. Yes, Microsoft runs too many things in kernel mode, but the kernel itself isn't as vulnerable as you claim. And certainly not by design. -
Re:Where's the evidence???First, as pedantic as it may sound, the kernel itself is very much seperate than other things that run in kernel mode. Kernel mode drivers are just DLLs.
How about the 'Client Server Run-time Subsystem'?
Otherwise known as the win32 server. Yes, since NT4 most of it moved into kernel mode (win32k.sys) to reduce overhead. Before that, it was all in csrss.exe and csrsrv.dll, both entirely user-mode.How about Netbios?
netbios.sys does run in kernel mode; it's a network protocol driver. Is it so bad to have a protocol driver in kernel mode?How about the Virtual DOS Machine (VDM)?
Most of that runs in ntvdm.exe with some kernel support so it can use v86 mode. Surely you want CPU protect mode control in the kernel?The program iexplore.exe is run in userspace, but the majority of the functions of the browser are not in the program, but in the OS itself. It is certainly not a solely user-space program.
Yes it is. It is integrated with the Windows shell, but not anything in kernel mode. It depends on what you mean by operating system. Most of IE's code is in shell32.dll, mshtml.dll, shdocvw.dll, ole32.dll and browseui.dll; all of which run exclusively in user mode.The fact that Windows system security is crap should not be used to disregard the Windows Kernel problems, after all, it's the kernel that this thread is all about.
The Windows NT security model is designed quite well; MS's security problems are in their poor implementation. Here is a good post about the difference.First off, I listed FOUR, count 'em, 4 exploits that affect XP. Second, I clearly said, in no uncertain terms, that this was a quickly-compiled, partial list. I listed less than half the Microsoft kernel exploits my quick search found.
Several of them go to the same vuln; the one that requires the debug priveledge that normally only admins have anway.
This one is in CSR not the kernel.
This one is in the mup.sys driver, not the kernel.
This one is a DOS attack in the netbios driver, not the kernel.
This is an uninitialized disclosure of data that would be extremely unpredictable to get anything out of.
This is a serious hole.
The others are at best DOS attacks, not even priveledge escilations. Yes, Microsoft runs too many things in kernel mode, but the kernel itself isn't as vulnerable as you claim. And certainly not by design. -
Re:Where's the evidence???First, as pedantic as it may sound, the kernel itself is very much seperate than other things that run in kernel mode. Kernel mode drivers are just DLLs.
How about the 'Client Server Run-time Subsystem'?
Otherwise known as the win32 server. Yes, since NT4 most of it moved into kernel mode (win32k.sys) to reduce overhead. Before that, it was all in csrss.exe and csrsrv.dll, both entirely user-mode.How about Netbios?
netbios.sys does run in kernel mode; it's a network protocol driver. Is it so bad to have a protocol driver in kernel mode?How about the Virtual DOS Machine (VDM)?
Most of that runs in ntvdm.exe with some kernel support so it can use v86 mode. Surely you want CPU protect mode control in the kernel?The program iexplore.exe is run in userspace, but the majority of the functions of the browser are not in the program, but in the OS itself. It is certainly not a solely user-space program.
Yes it is. It is integrated with the Windows shell, but not anything in kernel mode. It depends on what you mean by operating system. Most of IE's code is in shell32.dll, mshtml.dll, shdocvw.dll, ole32.dll and browseui.dll; all of which run exclusively in user mode.The fact that Windows system security is crap should not be used to disregard the Windows Kernel problems, after all, it's the kernel that this thread is all about.
The Windows NT security model is designed quite well; MS's security problems are in their poor implementation. Here is a good post about the difference.First off, I listed FOUR, count 'em, 4 exploits that affect XP. Second, I clearly said, in no uncertain terms, that this was a quickly-compiled, partial list. I listed less than half the Microsoft kernel exploits my quick search found.
Several of them go to the same vuln; the one that requires the debug priveledge that normally only admins have anway.
This one is in CSR not the kernel.
This one is in the mup.sys driver, not the kernel.
This one is a DOS attack in the netbios driver, not the kernel.
This is an uninitialized disclosure of data that would be extremely unpredictable to get anything out of.
This is a serious hole.
The others are at best DOS attacks, not even priveledge escilations. Yes, Microsoft runs too many things in kernel mode, but the kernel itself isn't as vulnerable as you claim. And certainly not by design. -
Re:Where's the evidence???First, as pedantic as it may sound, the kernel itself is very much seperate than other things that run in kernel mode. Kernel mode drivers are just DLLs.
How about the 'Client Server Run-time Subsystem'?
Otherwise known as the win32 server. Yes, since NT4 most of it moved into kernel mode (win32k.sys) to reduce overhead. Before that, it was all in csrss.exe and csrsrv.dll, both entirely user-mode.How about Netbios?
netbios.sys does run in kernel mode; it's a network protocol driver. Is it so bad to have a protocol driver in kernel mode?How about the Virtual DOS Machine (VDM)?
Most of that runs in ntvdm.exe with some kernel support so it can use v86 mode. Surely you want CPU protect mode control in the kernel?The program iexplore.exe is run in userspace, but the majority of the functions of the browser are not in the program, but in the OS itself. It is certainly not a solely user-space program.
Yes it is. It is integrated with the Windows shell, but not anything in kernel mode. It depends on what you mean by operating system. Most of IE's code is in shell32.dll, mshtml.dll, shdocvw.dll, ole32.dll and browseui.dll; all of which run exclusively in user mode.The fact that Windows system security is crap should not be used to disregard the Windows Kernel problems, after all, it's the kernel that this thread is all about.
The Windows NT security model is designed quite well; MS's security problems are in their poor implementation. Here is a good post about the difference.First off, I listed FOUR, count 'em, 4 exploits that affect XP. Second, I clearly said, in no uncertain terms, that this was a quickly-compiled, partial list. I listed less than half the Microsoft kernel exploits my quick search found.
Several of them go to the same vuln; the one that requires the debug priveledge that normally only admins have anway.
This one is in CSR not the kernel.
This one is in the mup.sys driver, not the kernel.
This one is a DOS attack in the netbios driver, not the kernel.
This is an uninitialized disclosure of data that would be extremely unpredictable to get anything out of.
This is a serious hole.
The others are at best DOS attacks, not even priveledge escilations. Yes, Microsoft runs too many things in kernel mode, but the kernel itself isn't as vulnerable as you claim. And certainly not by design. -
Re:Where's the evidence???
That vulnerability requires the SeDebugPrivilege in order to exploit. It is normally (default) only given to members of the Administrators group. If a program is running as admin, then it is already a huge security hole. See http://www.securityfocus.com/archive/1/354392.
-
Re:Sasser FUn!I almost can't blame the customers for doing this. Ever try just updating windows xp over broadband? Takes forever.
What's even worse is the fact that most internet users are still stuck on dialup! According to this recent article at CBS, 3 out of 5 internet users don't have broadband.
The very issue of security patches, their sizes, and the problems for dialup users trying to download them was covered here as well.
-
Re:Heard of a firewall?
-
Re:So...
However, you might notice that at least one critical advisory that affected Windows 98 never had a patch released through Windows Update or for download.
The ASN.1 vulnerability affects Windows 98, but MS would only release the patch to you if you had a contract or called them about it. See here. How many people are going to call MS about it? How many Windows 98 machines are now operating on the Internet blissfully, ignorantly vulnerable?
-
Re:I was wondering...
a firewall is essential.
It sure is. The last worm wouldn't have worked without one. -
Re:Blaming the user
What is also sad is that some home routers are also setup terribly by default. Such as one from SMC that had remote administration enabled by default! So much for "putting your machine behind a NAT router to keep it secure" when it defaults with a gaping security hole that if most users don't specifically do something about this, they could still end up being compromised behind their router due to it allowing anyone to remotely login and change its settings. Using that gaping hole, an attacker could and still attack computers behind the very thing they thought was protecting them.
-
Re:I left my heart in San Fran
A Visit from the FBI
Also, it was a Slashdot story. FBI Agent Talks Crime, Macs -
Re:What's the problem here?
Of course, Slashdot would run a story that debates a treaty with a link to the treaty language itself [privacyinternational.org] because we reject all government actions without even needing to read what they're proposing.
Considering the treaty was clearly linked in the original article (check out the underlined and different colored hyperlink), I kind of thought it was redundant. Guess I underestimated the number of -
Re:Qmail
-
Re:A big shout out to teh postfix guys
-
Re:Qmail
-
What about fragmentation?
From my daily reading it looked like the recent mailing regarding the Rose attack Which could affect nearly as many systems as this TCP vulnerability. With two vulnerabilities of this extent, and their relative quiet reception by the security community I don't think there will be much of a push to fix this problem, while the k1dd13s go to work acquiring proof of concepts.
-
Re:It's easy to make them paranoid about using DOC"Dear Sir or Madam,
Recently you sent an email containing a Windows Bitmap. Due to security and virus concerns [our company] cannot accept those attachments.
Please send a photograph to transmit future documents to me.
Thank you for your time.
-Adam"
Using security as an excuse to deny the acceptance of Word Documents is FUD.
There is *no* security risk in *any* attachment, only in the applictions used to process them.
We've recently seen buffer overflow exploits in *many* email clients without even getting as far as *opening* the documents.
Here's just a few
-
Re:Sorry to burst your bubble, guys
But the people pointing out the one-sided reporting on Slashdot are right.
Says who?
Look again at that list of announced vulnerabilities. It does include some common Linux programs, like kde and the kernel. But what the heck is "fte"? I assume that "oftpd" is an ftp daemon, but I've never heard of it. "portage" is vulnerable only on Gentoo, of course, because it's the only one which has it. And "ClamAV"? Great, now "Linux vulnerabilities" incude every commercial product which run on Linux.
See the problem here? You're comparing a wide variety of Linux software to just core Windows vulnerabilities. Of course there will be lots of Linux vulnerabilities if you count every program out there. But realistically, most people don't care if "interchange" (whatever that is) has a remote information disclosure vulnerability.
Which, by the way, is a second point: some vulnerabilities are too small to be front-page news. A bug which allows a DoS on some obscure FTP server just isn't news.
Comparing apples and oranges is pointless enough, but some people only seem to be capable of _counting_ the number of apples and oranges, so that's what they compare. That is truly pointless. -
Re:Sorry to burst your bubble, guys
But the people pointing out the one-sided reporting on Slashdot are right.
Says who?
Look again at that list of announced vulnerabilities. It does include some common Linux programs, like kde and the kernel. But what the heck is "fte"? I assume that "oftpd" is an ftp daemon, but I've never heard of it. "portage" is vulnerable only on Gentoo, of course, because it's the only one which has it. And "ClamAV"? Great, now "Linux vulnerabilities" incude every commercial product which run on Linux.
See the problem here? You're comparing a wide variety of Linux software to just core Windows vulnerabilities. Of course there will be lots of Linux vulnerabilities if you count every program out there. But realistically, most people don't care if "interchange" (whatever that is) has a remote information disclosure vulnerability.
Which, by the way, is a second point: some vulnerabilities are too small to be front-page news. A bug which allows a DoS on some obscure FTP server just isn't news.
Comparing apples and oranges is pointless enough, but some people only seem to be capable of _counting_ the number of apples and oranges, so that's what they compare. That is truly pointless. -
Re:Meh.
Are you sure that you're secure, just because your router uses firmware? Most firmware is stored in flash memory nowadays, and I've already seen exploits upload their own code to some of those nice NAT boxes. By doing a bit of research on bugtraq or other full-disclosure mailing lists, you'll quickly dig up a few announcements... Now, how often do you update your firmware?
-
phew
from my logs [Mon Apr 12 16:29:53 2004] [error] [client 64.229.154.62] request failed: URI too long
from the articlenot vulnerable Apache Software Foundation
Apache 1.3.29
Apache Software Foundation Apache 2.0.48
+ Trustix Secure Linux 2.0
+ Trustix Secure Linux 2.1
From my machine $ httpd -v
Server version: Apache/1.3.29 (Unix)
Server built: Nov 3 2003 19:54:39 -
Additional Information
Oddly enough, while writing a comment to another user's message, I threw some info in google to learn about FirstEnergy's EMS system, and found this other SecurityFocus story in Feburary 2004, which gives more raw facts than this newer story.
"DiNicola said Thursday that the company, working with GE and energy consultants from Kema Inc., had pinned the trouble on a software glitch by late October and completed its fix by Nov. 19..."
"With the software not functioning properly at that point, data that should have been deleted were instead retained, slowing performance, he said. Similar troubles affected the backup systems. " This dovetails well with why the testers had to "slow" their testing to make the race condition appear.
-
Re:Only interview?Umm, there were about half a dozen articles covering Lamo on securityfocus, and 22 articles about him overall... none were an actual "interview" per se, but Kevin Poulsen quoted him several times after talking with him on the phone.
And you didn't have to wait six months to see that... use their search engine to find all 22 articles...
-
Security Focus
SF carried an article a couple of months ago regarding software bug that contributed to the blackout.
-
Re: The point everyone misses
-
Re:Innovative, isn't it ?
Actually, no, a no-execute bit doesn't prevent buffer overflow attacks. It just stops an attacker from directly executing code that he/she left lying around on the stack or heap. However, return-into-libc exploits are still possible, and although they're a bit trickier to write, they aren't really mind-blowingly difficult, either.
-
Too harsh on the US governmentYou people are being too harsh on the US government. Now that we'll have all these fingerprints, we'll be able to PROVE who hijacked a plane that crashes into a building!
Hackers Claim New Fingerprint Biometric Attack
How To Fake Fingerprints
Doubt cast on fingerprint security -
Arrghh...
Oh when will april fools be over... How about when SCO thanks Redhat.. Hey, what do you know
-
Re:PowerPod != iPowerPod
People jokingly announce really cool things that have no chance in hell of ever coming out.
Yeah. Like this joke on SecurityFocus about Microsoft improving security. -
Robin HoodFirst off, there are a couple of links to articles describing what happened, the Security Focus article was the most informative.
So we've got this guy working for an insurance company who decides to inform the Dept. of Insurance that they are cancelling policies unlawfully. This is a good thing and brave of him to do it. Hopefully his motivations were purely good and not just because he was pissed he didn't get a raise last year or something.
And let's face it, insurance companies are the some of the worst kinds of organizations in corporate America. They collect huge sums of money via premiums - that are based in people's fear that something terrible could happen. And then as soon as you need them (you have an accident, someone in your family gets ill, etc.), they immediately initate every effort to not pay you in your time of need. I know it's how they do business, but it's a disgrace. I have experienced this first hand more than once
Back to the story, the guy then plants a keystroke logger on a secretary's PC in order to collect further info for his crusade and to aid lawyers in a class action suit against his company. He obviously crossed a line here. And in the middle of this, he finds himself fired (curious). So he asks a former co-worker to retrieve the logger for him? And of course being a good insurance company employee, she rats him out.
I applaud his intentions, if they were indeed based in fairness and the public good. He did get carried away for sure by planting the bug. But I can't believe the stupidity of (1) admitting he planted it to a former co-worker and (2) expecting her to help him retrieve it and f--k the company she still worked for. I guess he really was a bit of a dreamer
-
Re:Save yourself some reading
You are failing to consider the extent to which Windows internal architecture dictates the software running on the platform.
Most of the time Microsoft bashing is valid, but saying that this is Microsoft's fault in any way is about one step away from stupid.
If this was the fault of Windows, a buffer overflow such as this one could not happen under Linux/MacOS/FreeBSD/Netware etc etc etc. However, a quick search on SecurityFocus tells us that it did infact happen on all the platforms listed above.
So, please explain to me how Microsoft can be blamed for this in any way!
...and saying that they should not allow code-execution on the stack or make it more secure so you dont need a firewall are not valid arguments. -
Re:Switch!!!
It could have happened in the past. Pine has had similar vulnerabilities in the past.
-
Re:Switch!!!
Sure. Just install a good software firewall like Black Ice, and you're good to put that Windows box on the Internet.
http://www.securityfocus.com/news/8291 -
ATM OS diversityAround here, quite a few ATMs are still running OS/2 For some weird reason, they - just like the ATM the article talks about - have a tendency to crash, reboot and not load the ATM interfacing software.
I got a chance to talk to one of my bank's IT people about this a few months ago, and basically, they don't know what's causing the crashes because analyzing the log files would just be too much trouble. So their SOP is to have some guy with a key come out, literally pull the plug on the machine and wait till it reboots.
He also told me that they were slowly migrating over to a "custom XP version", whatever that's supposed to mean. I probably should have told him that Windows machines can be prone to virus infections (cough cought).
-
Re:Non-Exploitable Security DOS Exploit
none of them (including Microsoft) collect any actual personally identifiable information.
I thought that they backed off from that commitment. It was definitely well touted in the early days of Windows Update "this program will never send information that is personally identifiable". But they seem to have changed their mind. -
Re:A good reason to use encryption
Yeah, and not just humans either. The worms are starting to use encryption too. Some versions of Bagle are spreading themselves in password encrypted Zip files, with the password in the message body. The pace of the arms race is incredible. Antivirus vendors then updated their scanners to scan the message body for the Zip file password and decrypt the attachment. The virus writers then started sending the password in a bitmap attachment to foil the virus scanners.
Of course that story was from 2 weeks ago so it's old news. This week the latest variant has no attachment at all. It's just HTML that exploits an IE bug that downloads the worm from the infected computer that sent the message. -
Re:A good reason to use encryption
Yeah, and not just humans either. The worms are starting to use encryption too. Some versions of Bagle are spreading themselves in password encrypted Zip files, with the password in the message body. The pace of the arms race is incredible. Antivirus vendors then updated their scanners to scan the message body for the Zip file password and decrypt the attachment. The virus writers then started sending the password in a bitmap attachment to foil the virus scanners.
Of course that story was from 2 weeks ago so it's old news. This week the latest variant has no attachment at all. It's just HTML that exploits an IE bug that downloads the worm from the infected computer that sent the message. -
Re:3 TIMES!
How hard could it be to install a virus-scanner, proxy server (squid anyone?), and a firewall? Then only leave open necessary ports (25, 110, 443, 80, etc). How come government is given a free pass when it comes to incompetence? If stuff like this happened in the private sector, shareholders would be calling for heads on platters.
Right, that's why vulnerabilities are never reported in commercial software. Oh, wait -- they are.
If you think
The fact is that the U.S. government is not so bad at security as a some folks seem to think. Yes, federal employees don't often get fired, but guess what: most IT systems management is done by contractors, who are quite easy to replace.
Also, I have news for you: the techniques you have in mind don't protect you against a huge variety of attacks. Many compromises these days exploit vulnerabilities in vendor-supplied web-based products, which are totally exposed in your rudimentary protection regime. Your ideas about how to protect a network are fine when you've got one
-
Another article on this subject...
...over at SecurityFocus - Voice over IP Security by Matthew Tanase
-
That was covered in part 1 of that article
See part 1 and look for "Reverse lookup".
-
Rebuttal/Solution/Sales pitch-mod up if merited...
My credentials are years of programming experience and months of research invested in CF13(TM), my solution to English-language spam.
Part I of the article:
Identity theft - The ones I got were relayed through a 3rd party machine and deemed spam. Should I ever get a 'real one' that would mean either a spammer is using a stolen/throwaway account at a domain with mailserver(s) and easily traceable, or, worse yet, an 'inside job' by someone unscrupulous at the sender domain. The rule of thumb is to not give out sensitive information via email no matter how convincing said email is.
Viruses - All attachments are treated as 'text files' by my program and are 'harmless' provided a certain registry key affecting Notepad hasn't been changed/hijacked (see my website for more details). Also, all email is downloaded and treated as text files, making HTML related exploits impossible as well.
Sender - Anonymous senders are treated as spam. No exceptions. I've only gotten spam from such senders the rare times I recived them before I wrote my program.
Recipient - No 'BCC:' email if desired. In the past, such email I've recieved were spam.
Word lists - My program uses two of them. One of them is the single word list from Grady Ward's Moby project. The other file contains 'spam words' that appear in the first file. Both lists make 'hashbusting' and 'L33T' spelling, two tried and true spammer tactics, impossible.
Black/White lists - Supported at the email address and email domain level. I decided not to support IP level black/whitelisting since the IP source of spam is irrelevant--it is the content of spam that is relevant. Likely, such spam is deemed spam at the email header level anyway--or at the email message content level if need be.
Hash-tables - Pointlest due to 'hashbusting' and 'L33T' spelling. Unecessary in my program.
AI/Probabilistic systems - I researched the Bayesian approach and decided not to use it in my program. Though effective at first, spammers have thoroughly 'poisoning' this method of spam detection. Also, this method requires additional disk storage space, processor time (to do the math calculations on top of the pattern matching), and training time to be effective.
Bypassing filters - A default install of my program should catch almost all spam. Should any get through, one could read through the spam and identify new 'spam words' to be added to that list.
False-positives - Alas, to avoid deleteing such email at the server level, All such email is downloaded and processed. My program displays the subject lines of email messages it process and logs them to a separate file for further review if needed.
Spam filters do not stop spam - Agreed, but they can be as effective as my program which only has one known form of spam it cannot detect sent by a spammer from a stolen/throwaway account.
Reverse lookup - Not supported in my program to avoid slowing my program down and not overburdening the (likely) overtaxed DNS server system. This should be handled at the mailserver level to head off the sending of spam in the first place.
Part II of the article:
Challenge-Response - I considered using this but decided against it. In doing so I avoid 'mail loops' with another Challenge-Response system and outright rejection by email correspondents who hold a dim view of this antispam system.
Computational challenge: Another idea that fell by the wayside due primarily to the wide disparity in the CPU clock speeds of user's systems.
Cryptography - Not used by my program to process incoming email and thus unecessary. The 'bu -
Rebuttal/Solution/Sales pitch-mod up if merited...
My credentials are years of programming experience and months of research invested in CF13(TM), my solution to English-language spam.
Part I of the article:
Identity theft - The ones I got were relayed through a 3rd party machine and deemed spam. Should I ever get a 'real one' that would mean either a spammer is using a stolen/throwaway account at a domain with mailserver(s) and easily traceable, or, worse yet, an 'inside job' by someone unscrupulous at the sender domain. The rule of thumb is to not give out sensitive information via email no matter how convincing said email is.
Viruses - All attachments are treated as 'text files' by my program and are 'harmless' provided a certain registry key affecting Notepad hasn't been changed/hijacked (see my website for more details). Also, all email is downloaded and treated as text files, making HTML related exploits impossible as well.
Sender - Anonymous senders are treated as spam. No exceptions. I've only gotten spam from such senders the rare times I recived them before I wrote my program.
Recipient - No 'BCC:' email if desired. In the past, such email I've recieved were spam.
Word lists - My program uses two of them. One of them is the single word list from Grady Ward's Moby project. The other file contains 'spam words' that appear in the first file. Both lists make 'hashbusting' and 'L33T' spelling, two tried and true spammer tactics, impossible.
Black/White lists - Supported at the email address and email domain level. I decided not to support IP level black/whitelisting since the IP source of spam is irrelevant--it is the content of spam that is relevant. Likely, such spam is deemed spam at the email header level anyway--or at the email message content level if need be.
Hash-tables - Pointlest due to 'hashbusting' and 'L33T' spelling. Unecessary in my program.
AI/Probabilistic systems - I researched the Bayesian approach and decided not to use it in my program. Though effective at first, spammers have thoroughly 'poisoning' this method of spam detection. Also, this method requires additional disk storage space, processor time (to do the math calculations on top of the pattern matching), and training time to be effective.
Bypassing filters - A default install of my program should catch almost all spam. Should any get through, one could read through the spam and identify new 'spam words' to be added to that list.
False-positives - Alas, to avoid deleteing such email at the server level, All such email is downloaded and processed. My program displays the subject lines of email messages it process and logs them to a separate file for further review if needed.
Spam filters do not stop spam - Agreed, but they can be as effective as my program which only has one known form of spam it cannot detect sent by a spammer from a stolen/throwaway account.
Reverse lookup - Not supported in my program to avoid slowing my program down and not overburdening the (likely) overtaxed DNS server system. This should be handled at the mailserver level to head off the sending of spam in the first place.
Part II of the article:
Challenge-Response - I considered using this but decided against it. In doing so I avoid 'mail loops' with another Challenge-Response system and outright rejection by email correspondents who hold a dim view of this antispam system.
Computational challenge: Another idea that fell by the wayside due primarily to the wide disparity in the CPU clock speeds of user's systems.
Cryptography - Not used by my program to process incoming email and thus unecessary. The 'bu -
Use Bayesian filtering
Yes, spam changes over time, but Bayesian filters naturally adapt over time. Of course, the downside is that as spam mutates you will get it in your inbox and have to manually mark it as spam, but I've found that this is somewhat more of perverse pleasure than a chore. (For more on why filters aren't an ideal solution, check out this article...)
-
More details in Part 1
The linked article is part 2, Part 1 is here.
-
Once again, it's not "stealing"
"Theft" is a very specifc criminal offense, and it has a legal definition. And the Supreme Court has already ruled on this matter: Copying Is Theft and Other Legal Myths "But technically, file sharing is not theft. A number of years ago, the U.S. Supreme Court dealt with a man named Dowling, who sold "pirated" Elvis Presley recordings, and was prosecuted for the Interstate Transportation of Stolen Property. The Supremes did not condone his actions, but did make it clear that it was not "theft" -- but technically "infringement" of the copyright of the Presley estate, and therefore copyright law, and not anti-theft statutes, had to be invoked. So "copying" is not "stealing" but can be "infringing." That doesn't have the same sound bite quality as Valente's position. "
-
protecting parents
I have been fighting this one myself. I just ended up reinstalling my mother's PC from scratch to clean it before she got her broadband installed. Now that she has it, I am very scared. All of the software is a start but parents really need to be forced into educating themselves on what dangers exist. Without the awareness, you can't eliminate the risk. That is at least without setting them up on a Mac which has been suggested but the reality is, that will only be a temporary solution. Macs are becoming more common and given their base in BSD, have already been seen to be more vulnerable than previous versions.
I recently posted a link to This Article on my site. It is a security checklist for home users released by security focus. It provides very basic explanations for a number of home security issues.
-
Re:DirecTV rules
Thank you ! ! !
Some "enforcement" actions must not be forgotten. Poulson also wrote an article about it.
Those targeted by this federally-aided sweep were not pirates (as an AC wrongly characterized it) - but people who bought legal equipment with other legitimate uses, which also could have been used to help pirate DirecTV programming. And some of the targets don't even own satellite dishes.
<grrr>