Microsoft has warned that a “critical” flaw in the latest versions of its Windows operating system could allow hackers to access a person’s computer. “This is one of the most serious Microsoft vulnerabilities ever released” said Mr Maiffret.
Microsoft Admits Critical Flaw
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
did it really take them over five years to discover this flaw? or did it take that long to fix it?
I know that bugs and flaws are unavoidable and often hard to discover at development level, but the development structures plays a big role in how many bugs it produces.
It seems to me once again that Windows is too large and complex for it’s own good.
yes it took them that long to discover this flaw in windows AND linux/unix. in unix this was fixed a few month ago.
it is just a little too early to wet your pants, there is no known exploit for it jet.
What about other security flaws. Like noone being able to review the source code, even if you bought the software. No peer review of the code to look for holes or vulnerabilities.
Hmmm…..
yes it took them that long to discover this flaw in windows AND linux/unix. in unix this was fixed a few month ago.
it is just a little too early to wet your pants, there is no known exploit for it jet.
Care to elaborate?
I found it odd that one expert said that MS delayed releasing a fix because if the vulnerability was announced, then it would be more likely that someone else would take advantage of this knowledge and exploit the weakness.
This is exactly opposite the Open Source philosophy. Perhaps there is a grain of wisdom in the assumption that one should keep one’s skeleton(s) in the closet as long as possible before burying them in a more discreet place. However, as the other expert said, if a business can claim they lost money because of this vulnerability when MS was aware of it, then MS should be liable for that company’s losses.
Personally, I think the Open Source philosophy is better because in MS’s way, they assume that because only they and the net security firm know of the vulnerability it’s less likely the vulnerability will be exploited by virtue of keeping it in the dark. But one has to wonder, if a security firm can find the answer, why can’t a dedicated hacker, or worse yet a team of funded hackers (why not? I mean terrorists could have a team of hackers). If the vulnerability is released publicly, then you have a world full of (good) hackers trying to outrace the bad hackers for a fix to the problem. So you level the playing field a bit more, but at least one removes some of the liability concerns.
I always find it amusing when these so-called Windows vulnerabilities are announced. The Linux zealots try to act like it’s some sort of chaotic ordeal of holes and breaches when using Windows, when there are never any exploits until these things these things are announced anyway. I guess they’re too busy ignoring the fact that GNOME, Gentoo, and Debian got hacked–and GNU got hacked twice–all in the span of six months.
“I guess they’re too busy ignoring the fact that GNOME, Gentoo, and Debian got hacked–and GNU got hacked twice–all in the span of six months.”
Twice, in six months? whoa, dude you’re right, Linux is terrible.
I mean compared to the minor hitches in windows like;
W32/Mydoom.C or W32.HLLW.Doomjuice
W32/Mydoom or W32/Novarg
W32/Beagle or W32/Bagle Worm
Multiple Vulnerabilities in Microsoft ASN.1 Library
HTTP Parsing Vulnerabilities in Check Point Firewall-1
Multiple Vulnerabilities in Microsoft Internet Explorer
Multiple H.323 Message Vulnerabilities
Buffer Overflow in Windows Workstation Service
Multiple Vulnerabilities in Microsoft Windows and Exchange
Microsoft IE URL display vulnerability
All in the last 3 months, i guess windows is just as well designed and written as any modern commercial or none-commercial operating system!
Please tell me what unpatched security holes MyDoom is exploiting. And please note that open source’s starlet, Mozilla Firebird (now FireFox) was also affected by the IE URL display vulnerability. The IE patch was released before the next release of Firebird, for what it’s worth. And if you did grab a nightly to fix that bug, many users were affected by a bug that deleted all of the Program Files. OOPS!
From /.
“Yes. This isn’t the third DIFFERENT bug in ASN.1 discovered recently – this is the third set of applications using the SAME REFERENCE IMPLEMENTATION of ASN.1 that was discovered to be vulnerable once it was discovered that the reference implementation was buggy. SNMP and SSL got hit, then just recently H.323 got hit, and I don’t know what Microsoft parts just got hit”
2 points:
1) Monoculture sucks.
2) Microsoft’s Patches are late.
URL spoofing patch took Microsoft 2 months or so. _60_ days!
Here’s another list of unpatched stuff:
http://www.eeye.com/html/Research/Upcoming/index.html
Finally, MSIE’s SSL implementation is still broken making sniffing child’s play (https:// == http:// in MSIE; it adds just this: NOTHING). Besides other vulnerabilities which still haven’t been fixed.
DF: You really think the fact a site got chracked X times by definition correlates with the security of the OS they’re running and time they take to patch a bug…?? … .
And GNU, these hippies have been way too easy with security on their computers. But that doesn’t say anything about ie. RedHat Linux’s (the OS) security. Doh! Btw the 2nd one was in 6 months the other one was near march or april ’03, so it’s only 1 time. Debian got rooted via a 0-day 3zpl01t (which is NO sign of bad timespan of patching itself). Thanks to the Debian project’s forensics and kernel hackers, this local root compromise got found. Gentoo was hardly affected by the rsync bug (no root iirc). And MPlayer are flaming morons who state that “the chracker hasn’t done anything bad in 10 minutes”… nice troll anyway.
“And if you did grab a nightly to fix that bug, many users were affected by a bug that deleted all of the Program Files. OOPS!”
Jebus!!!1!!1 Source?
“Please tell me what unpatched security holes MyDoom is exploiting.”
Outlook, forever.
With Linux, or whatever, local root compromises don’t upset me, because Linux exploits are largely local ones.
Whats worth pointing out is that its the majority of exploits in windows that are remote compromises.
I don’t care too much if someone breaks my Linux box AT my Linux box.
I’d hate to pay for a system where remote rooting is daily bread.
“I guess they’re too busy ignoring the fact that GNOME, Gentoo, and Debian got hacked–and GNU got hacked twice–all in the span of six months.”
When was GNOME cracked? I don’t remember that happening.
I mean compared to the minor hitches in windows like;
W32/Mydoom.C or W32.HLLW.Doomjuice
W32/Mydoom or W32/Novarg
W32/Beagle or W32/Bagle Worm
These do not exploit any design flaw in Windows, unless you count WinXP ZIP integration into Explorer as making it too easy to open .ZIP files and thus too easy for people to run executatbles contained within .ZIPs that arrive as e-mail attachments.
A similar virus could be written targeting Linux systems, but 1) the Linux userbase consists primarily of more educated (albeit condescending) users who do extract arbitrary .ZIP files arriving as attachments and excute their contents and 2) the Linux userbase is far too small for any virus writer to waste their time with.
Provided Linux users were stupid enough to open arbitrary attachments, the virus could add a cron job to ensure it stays running, set up a TCP listener to accept incoming commands, and then a local root exploit could be used for a full system compromise.
Multiple Vulnerabilities in Microsoft ASN.1 Library
Remember this OpenSSL ASN.1 parsing vulnerability:
http://www.cert.org/advisories/CA-2003-26.html
Or this one before that:
http://www.cert.org/advisories/CA-2002-23.html
HTTP Parsing Vulnerabilities in Check Point Firewall-1
Remember this vulnerability in Apache:
http://www.cert.org/advisories/CA-2002-17.html
Multiple H.323 Message Vulnerabilities
This was a multi-vendor vulnerability:
http://www.uniras.gov.uk/vuls/2004/006489/h323.htm
Which affected products from at least the following companies:
Avaya:
http://support.avaya.com/japple/css/japple?temp.groupID=128450&temp…)
CheckPoint:
http://www.checkpoint.com/techsupport/alerts/h323.html
Cisco:
http://www.cisco.com/warp/public/707/cisco-sa-20040113-h323.shtml
Microsoft:
http://www.microsoft.com/technet/security/bulletin/ms04-001.asp
and Nortel (no URL available)
Meanwhile, Linux has seen system level vulnerabilities in 3 of its system call implementations within the past year alone, including the ptrace vulnerability, a facility which had previously seen a system level compromise in 2002.
As I explained earlier in my e-mail virus example, these system call vulnerabilities can be used to transform any remote compromise (including an e-mail virus) into a system level compromise for any Linux system running a slightly older kernel. They completely blast away any concept of user level security.
All systems have vulnerabilities, but it’s ridiculous to compare an e-mail virus which exploits no flaws in the operating system with input validation errors in the system call table. For the Linux kernel to be unable to properly validate system calls at this point in time is completely ridiculous.
I always find it amusing when these so-called Windows vulnerabilities are announced. The Linux zealots try to act like it’s some sort of chaotic ordeal of holes and breaches when using Windows, when there are never any exploits until these things these things are announced anyway. I guess they’re too busy ignoring the fact that GNOME, Gentoo, and Debian got hacked–and GNU got hacked twice–all in the span of six months.
I can’t speak for the others because I don’t follow any of them but Gentoo did not get hacked. You’re just another WinTroll (Windows zealot, whatever) who likes to spread FUD. An rsync server was hacked, the server also mirrored other things. The OS was not even Gentoo. It was a hack that could have (but did not) affect Gentoo users but it was not a Gentoo specific exploit.
I think it’s funny when the WinTrolls come out to spout this nonsense when these exploits (for Linux and Open Source) are mostly local and even then they are discovered and taken care of immediately. At least I’m not the one using software that is being exploited for mass mailings.
“Please tell me what unpatched security holes MyDoom is exploiting. And please note that open source’s starlet, Mozilla Firebird (now FireFox) was also affected by the IE URL display vulnerability. The IE patch was released before the next release of Firebird, for what it’s worth. And if you did grab a nightly to fix that bug, many users were affected by a bug that deleted all of the Program Files. OOPS!”
Mozilla {Browser, Firefox, etc} were only *partially* affected. You could still see the full URL (unlike in IE, where it didn’t display the text that would reveal the site you were really at).
Also, the Program Files bug only affected installations where Firefox was installed into the Program FIles folder rather than Program FilesMozilla Firefox.
Provided Linux users were stupid enough to open arbitrary attachments, the virus could add a cron job to ensure it stays running, set up a TCP listener to accept incoming commands, and then a local root exploit could be used for a full system compromise.
I’d like to see you do that without first having root access. Just try and set up a cron job without being root.
Bascule turns it the other way around, but forgets to admit that monoculture is a Bad Thing. Instead he critizes (quite rightfully imo) the Linux kernel’s security. Somehow he also manages to completely forget the “time point”! Funny, these 2 were exactly my point. But yes, Linux has had quite a few local vulnerabilities in the kernel. Big deal, so has “secure by default” OpenBSD (yes, yes, in the kernel, which is “enabled by default”!). Noir++.
I’d like to see you do that without first having root access. Just try and set up a cron job without being root.
Doesn’t really matter – if it needs root access, it’ll ask for it, and Joe Sixpack would type in the password without thinking twice, especially if he’s accustomed to his computer asking him for the root password everytime he needs to do something with root access.
A lot of what makes Windows as insecure as it is are the people that use it. Most of us that use a little common sense are never affected by these vunerabilities. I’m not saying it isn’t bad, but it’s not nearly as bad as some people make it out to be. Same thing applies in the real world – if you leave your house unlocked in a bad neighborhood, you’re eventually going to get roobed.
There is a difference which I feel should be pointed out to some who are less informed than you or myself…
The difference is that most people running any form of
Windows are working as Admin. Even if the user becomes more educated and wants to work as a non-privileged user, she can’t because most applications are not written properly. Most applications still need to be run as Administrator in order to function correctly, even in Windows XP.
In the Linux world, it more often than not that users work as non-privileged users. So even if viruses did exists for Linux, the damage is confined to the non-privileged user id that executed it, keeping the main operating system safe.
Yes, in this case the user who launched the malicious code can lose her personal data, but the rest of the system and the other users will be safe in a standard configuration. However, the way to protect oneself in this situation would be to keep a separate user account for important data and a separate user account for daily computer usage.
Doesn’t really matter – if it needs root access, it’ll ask for it, and Joe Sixpack would type in the password without thinking twice, especially if he’s accustomed to his computer asking him for the root password everytime he needs to do something with root access.
Reading an attachment doesn’t require root access though. If your OS asked you for a password just to read an attachment, you would probably notice something a little fishy, considering no other attachment has probably ever required root access in the past. That is a big fat red flag right there.
I’d like to see you do that without first having root access. Just try and set up a cron job without being root.
Ahem…
man crontab ?
Every user on the system has their own crontab which may be edited with the -e command.
For example, from a Bourne shell:
export EDITOR=ed
printf “a
00 1 * * * mycmd
.
w
q
” | crontab -e
Can be used by any editor to run “mycmd” at 1AM
It seems that the OSnews forums gobbled up my \n’s. I’ll try escaping them…
printf “a\n00 1 * * * echo\n.\nw\nq\n” | crontab -e
“Most applications still need to be run as Administrator in order to function correctly, even in Windows XP.”
Simply not true, this is why “Run As” exists
“For the Linux kernel to be unable to properly validate system calls at this point in time is completely ridiculous.”
This hasn’t been the case for quite some time.
Check out SE Linux (http://www.nsa.gov/selinux), RSBAC (http://www.rsbac.org) and Systrace (http://niels.xtdnet.nl/systrace) for three of the most promising projects in this area.
which applications need to be run as admin on XP, name a few please, because i didn’t encounter even one in quite some time.
this thread shows quite well that win-trolls are as anoying as linux-trolls… monoculure may be a bad thing (not in the eyes of commercial application developer imho) but that is no excuse for not beeing objective.
This hasn’t been the case for quite some time.
What? Then explain these:
http://isec.pl/vulnerabilities/isec-0013-mremap.txt
http://www.kb.cert.org/vuls/id/301156
http://www.kb.cert.org/vuls/id/337238
http://www.kb.cert.org/vuls/id/176888
All of these vunerabilities arise from input validation errors in various system call implementations.
Check out SE Linux (http://www.nsa.gov/selinux), RSBAC (http://www.rsbac.org) and Systrace (http://niels.xtdnet.nl/systrace) for three of the most promising projects in this area.
You don’t seem to understand. None of these address the issue of improper input validation in system calls. Perhaps they could be used to set which users are permitted to use which system calls, but without brk() no application can have a heap, which would render the majority of programs useless.
System calls are the barrier which separates user from kernel space, and unless system call parameters are properly validated, this isn’t a particularly effective barrier. In the case of Linux, it has been compromised three times in the past year, more than any other operating system.
“which applications need to be run as admin on XP, name a few please, because i didn’t encounter even one in quite some time.”
Well, the sony media player that was pre-installed on my friends Sony laptop.
She couldn’t play cd’s and mp3’s with this software unless she was Admin.
Also, the file sharing software assume you’re running as on as Admin.
For example, bearshare, limewire, kaaza. They all have to be installed as Admin, and only the Amin has read/write access to the folders where the files are saved. The preferences for the programs are not saved per user but only once for the Admin. That means when she runs the program as an unprivileged user, the Admin’s preferences are loaded. She can’t modify the preferences as unprivileged.
I set her up an unprivileged user account, but it has just been problem after problem.
I’ll bet I can find more apps if I had the machine for a day or two.
>>
“Most applications still need to be run as Administrator in order to function correctly, even in Windows XP.”
Simply not true, this is why “Run As” exists
>>
That’s right. So you use Run As to run your file sharing app as Administrator. I believe that was the point.
>”I guess they’re too busy ignoring the fact that GNOME, >Gentoo, and Debian got hacked–and GNU got hacked twice–all > in the span of six months.”
Debian got hacked with the use of an stolen local password. No OS is inmune to that. Besides is really different to hack a single computer in months of hack work than writing a generic piece of code that can crash thousand of windows boxes…
And by the way is better to be a linux-zealot than a Windows-zealot you moron
seriously, harddisks are so large and cheap these days that it’s quite a mistery why there’s so many people who aren’t making backups. a mirror disk in each computer should be standard.
the problem though, is that people would probably use it as extra space anyway
the point that linux users are trying to make all the time that viruses only can destroy what’s in your home folder is pretty pointless for home users. because for a home user the stuff that you save there is the most important stuff, often files that can’t be recreated.
while the system is important, it’s not that big of a deal for a home user if it gets trashed. either he/she calls the teenboy next door to fix it or take it to a repair shop. sure it’s annoying but it’s not like it’s any valuable data that is being destroyed.
on a server though, it’s critical that the system is intact and running 24/7, it may also have a lot of other users on the server and their files may get trashed as well. but that’s not the situation for most home users.
>>
System calls are the barrier which separates user from kernel space, and unless system call parameters are properly validated, this isn’t a particularly effective barrier. In the case of Linux, it has been compromised three times in the past year, more than any other operating system.
>>
No system is perfect. When critical vulnerabilities are found in the Linux kernel, patches are created and released asap. It appears here that it took ms 6 months to create the patch??
And, can you claim that such vulnerabilities don’t exist in Windows? We certainly can’t prove it since we can’t see the source code. Considering it the time it took to release the patch, I have a hard time believing the same kind of vulnerabilites don’t exist in Win.
Mozilla {Browser, Firefox, etc} were only *partially* affected. You could still see the full URL (unlike in IE, where it didn’t display the text that would reveal the site you were really at).
Sorry, this is untrue. If you used %00 instead of %01, it worked on both Internet Explorer and Mozilla Seamonkey (as well as Firebird/Firefox).
Also, the Program Files bug only affected installations where Firefox was installed into the Program FIles folder rather than Program FilesMozilla Firefox.
Ah. I guess that will make you feel better when all your files are erased.
Hi
Windows will rule the world regarless of whether its secure or not. no use fighting it with wimpy operating systems
its microsoft guys
and we rule
http://www.kb.cert.org/vuls/id/176888
Quote: “Other Information
Date Public 03/26/2001
Date First Published 07/18/2001 02:59:17 PM
Date Last Updated 05/20/2002”
We’re in 2004. So that doesn’t count your 1 year claim (whatewver kind of important way of measuring that may be).
http://www.kb.cert.org/vuls/id/337238
“Red Hat Enterprise Linux kernel-2.4.21 does not perform adequate checking of eflags when in 32-bit ptrace emulation mode”
Red Hat. And:
“This vulnerability is reported to only affect kernels built for the AMD64 architecture.”
RedHat doesn’t use the generic kernel. That’s 2 of your URL’s down already.
http://www.kb.cert.org/vuls/id/301156
True. That’s one. Other one also.
Now, may i search for 2 local compromises in the kernel of Free, Open and NetBSD in this very topic about “Microsoft Admits Critical Flaw”?
)) i’d love to!!!1!111!!1111
“Ah. I guess that will make you feel better when all your files are erased.”
The point is no sane person installs it in the non-default Program Files folder. Why not install everything in C: if you like a mess (:
This discussion is so funny! I’m gonna print this out!
There are many programs still in a buisness enviroment that dont work with a user account that have been installed under a admin and even with adjusting the reg and filepermisions on the app dir. There are VPN clients, CRM apps, Accounting apps, CAD apps, and much much more.
Hm so lets look at the solution that someone posted
Use the run as command with the Admin account/pass?
1. It brings up the admins profile..thus ignoring user settings/profile and any GPO settings for that user
2. Yeah sure..great I want to give my users that info. While your at it have some unlicensed software you can install as well.
3. Im also not intrested in security..run that app in the admin account so any security issues can be passed to the system acoount and root the box. Thats the reason your logged in as a user..so you can run apps as an admin
Run as doesnt help all the time.
You are misunderstanding. If you installed to X:Program FilesMozillaFirebird instead of X:Program Filesmozilla.orgMozillaFirebird, it would erase all of your X:Program files. This was a big freaking problem when the builds defaulted to the behavior February 6th.
Why doesn’t M$ just admit that Windows is a flaw and start selling Linux?!
/dev/null
It’s like this, most the people that read this site work in or around IT. The linked article is clearly written to be read by people like my grandparents. The linked article is just someones useless opinion. Why not just link to eEye so I don’t have to put up with BBC’s useless opinions? http://eeye.com/html/Press/PR20040210.html
“If you installed to X:Program FilesMozillaFirebird instead of X:Program Filesmozilla.orgMozillaFirebird, it would erase all of your X:Program files. This was a big freaking problem when the builds defaulted to the behavior February 6th.”
How is that the same as:
“Also, the Program Files bug only affected installations where Firefox was installed into the Program FIles folder rather than Program FilesMozilla Firefox.”
S/he clearly claimed something different based on which i drawed the other sentence.
Do you have a link? Which versions are affected? Windows-only? What exactly was the malicious code? Etc, basically the advisory…
Ahem…
man crontab ?
Every user on the system has their own crontab which may be edited with the -e command.
What garbage cron and distro are you running? You CANNOT setup a cron job unless you are root on my machine and THIS IS THE DEFAULT CONFIGURATION. I guess this is just another reason to support OS diversity.
Sorry, this is untrue. If you used %00 instead of %01, it worked on both Internet Explorer and Mozilla Seamonkey (as well as Firebird/Firefox).
You’re wrong. I just tested it out. Moz is only partially affected. Try it out for yourself:
http://www.secunia.com/internet_explorer_address_bar_spoofing_test
Bascule again has it wrong by dpi (IP: —.ipv4.freeshell.bofx.net)
We’re in 2004. So that doesn’t count your 1 year claim/RedHat doesn’t use the generic kernel. That’s 2 of your URL’s down already.
*sigh* Apparently I searched too quickly expecting people to be up to speed on the ptrace, brk, and mremap vulnerabilities. Guess not. Since you’re nitpicking, here’s the second ptrace vulnerability:
http://icat.nist.gov/icat.cfm?cvename=CAN-2003-0127
3/31/2003 – The kernel module loader in Linux, Linux kernel, 2.2.x before 2.2.25, and 2.4.x before 2.4.20, allows local users to gain root privileges by using ptrace to attach to a child process that is spawned by the kernel.
3/31/2003, that would certainly be within a year’s time.
Once again I get a condescending reply from an overzealous Linux user who cares more about the literal interpretation of my post than reality.
http://www.kb.cert.org/vuls/id/176888
^^^ This URL was posted to show that Linux saw similar vulnerabilities in the same facility. This means that this facility was not thoroughly audited for further vulnerabilities, which seriously calls into question whether or not we’ll see subsequent vulnerabilities this or other kernel features which have been recently exploited.
Now, may i search for 2 local compromises in the kernel of Free, Open and NetBSD in this very topic about “Microsoft Admits Critical Flaw”?
)) i’d love to!!!1!111!!1111
Neither FreeBSD, OpenBSD, NetBSD, Windows, or any other major operating system has seen three system call vulnerabilities in such a short period of time (1 year). Since Linux users keep blathering that Linux is a kernel and thus cannot be compared across the board to other operating systems, I am comparing kernels to kernels. In this comparison, the Linux kernel is a clear security loser.
RE: Bascule By Abraxas (IP: 69.37.33.—)
What garbage cron and distro are you running? You CANNOT setup a cron job unless you are root on my machine and THIS IS THE DEFAULT CONFIGURATION. I guess this is just another reason to support OS diversity.
I don’t know how cursory your knowledge of system administration is, but I can assure you, with a decade of system administration experience on multiple Unix-derived operating systems (and various Linux distributions) that every system I have used allows users to edit their own crontabs *per default* using the “crontab” utility.
Did you try typing “man crontab” yet?
Have you tried running “crontab -e” as a normal user?
I never cease to be amused by the relationship between an overly zealous attitude and a complete lack of knowledge or experience…
Here’s another one:
http://zeus.jesus.cam.ac.uk/~jg307/test/exploit.html
That one displays the difference between %00 and %01. The name in the status bar that appears on mouseover will be spoofed for Moz but not in the actual address bar, which is really what matters.
i_code_too_much: Even if the user becomes more educated and wants to work as a non-privileged user, she can’t because most applications are not written properly. Most applications still need to be run as Administrator in order to function correctly, even in Windows XP.
I’m not aware of any besides some very special programs that I own and I have several CD cases not quite filled, that each hold 200 CDs. (All legal, I’ve built up my collection over many years) Out of all of them the only really wierd one that I have found so far is a wallpaper changer that requires the user to either be an Administrator or very oddball permisions which will basicly render the user as a “virtual” administrator.
There are quite a few that initially appear as if they require an administrator to run, but once you adjust a few file permisions or what have you, the problem disappears and “suddenly” you can run it as a normal user.
Honestly, I don’t run any file sharing apps or the Sony program you mentioned later, so I can’t speak for those. But if they’re like the others I’ve worked with, they just require some fiddling.
Also, it should be noted that I never give anyone Administrator access to any computer I setup (even if it’s their own) and strangely enough, there have been no problems with any programs.
Also, all the Windows networks I have seen for some time are all setup so that the user does not have Administrator privledges and I never here any complaints from those users either.
Did you try typing “man crontab” yet?
Have you tried running “crontab -e” as a normal user?
I never cease to be amused by the relationship between an overly zealous attitude and a complete lack of knowledge or experience…
Just to let you ridicule yourself even further…
crontab -e
Permission denied
So what was your point again? I don’t need to show you the output of “man cronjob” because it’s useless and I’ve read it a thousand times before. It’s not my fault your box is not setup properly, and it’s certainly not Linux’s fault.
You still haven’t mentioned what distribution you are running.
crontab -e
Permission denied
This can occur for a number of reasons, such as settings in /etc/cron.allow or /etc/cron.deny, or perhaps your ‘crontab’ is not properly setuid, or the permissions on your cron spool are set improperly. Or perhaps the file pointed to by your EDITOR variable is not +x. There are dozens of problems which could cause that, and it’s rather ignorant of you to assume from this that the default behaviour of Unix and Unix-like systems is to disallow users from editing their own crontabs per default.
So what was your point again? I don’t need to show you the output of “man cronjob” because it’s useless and I’ve read it a thousand times before.
You’ve read “man cronjob” a thousand times before? That’s funny…
% man cronjob
No manual entry for cronjob
It’s not my fault your box is not setup properly,
My “box”? You mean the dozens of Solaris 8/9, Linux, and Solaris systems I maintain at work?
and it’s certainly not Linux’s fault.
I’m not dismissing that your distribution may not let users edit crontabs per default, but it is certainly not the norm. If you are running standard RedHat or Debian, something has been altered from the default configuration. Both of these distributions allow users to edit crontabs per default.
it’s rather ignorant of you to assume from this that the default behaviour of Unix and Unix-like systems is to disallow users from editing their own crontabs per default.
No, No, No. I never said that. Never mentioned Unix. It was you who implied that all Linux and Unix systems were vulnerable to that kind of exploit. It is simply not true. This is an OS flaw, not a Linux flaw. I can assure you this is the default configuration as I have several machines set up right here in front of me.
You’ve read “man cronjob” a thousand times before? That’s funny…
% man cronjob
No manual entry for cronjob
Congratulations you caught a typo.
You still haven’t mentioned what distribution you are running.
That doesn’t matter as much as “what cron do you use?”
vixie-cron
it’s rather ignorant of you to assume from this that the default behaviour of Unix and Unix-like systems is to disallow users from editing their own crontabs per default.
If there is no “cron.allow” or “cron.deny” then only the superuser has permission to use crontab. Adding a user does not require you to create and/or edit the “cron.allow” or “cron.deny” files. These actions may be caused by some automated script involved in adding users to the system but it is by no means necessary. It is certainly not a “Linux” problem.
Oi!
“Once again I get a condescending reply from an overzealous Linux user who cares more about the literal interpretation of my post than reality.”
Haha! I’m currently not even behind a computer with Linux, instead i’m using something entirely different. I’m wondering, why flame when you have such good arguments?
Anyway, with the other Ptrace (the earlier one you mentioned was similair in the *BSD’s), that makes it 3.
Now it’s my shot. Aieeeee!
FreeBSD, excluding any unpatched or unknown.
Taken from:
http://www.freebsd.org/security/
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-04:02…
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-03:17…
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-03:10…
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-03:09… (5.0 only)
That’s 4 local compromises in the kernel already.
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-02:44… (slightly older than the 1 year “scientific meassure”)
NetBSD, excluding any unpatched or unknown.
Taken from:
http://www.netbsd.org/Security/
ftp://ftp.netbsd.org/pub/NetBSD/security/advisories/NetBSD-SA2003-… (just like FreeBSD)
ftp://ftp.netbsd.org/pub/NetBSD/security/advisories/NetBSD-SA2003-…
http://www.secunia.com/advisories/10806/ (same as earlier FreeBSD bug; fixed in CVS)
OpenBSD, excluding any unpatched or unknown.
Taken from:
http://www.openbsd.org/errata.html
ftp://ftp.openbsd.org/pub/OpenBSD/patches/3.4/common/010_sysvshm.p… (same as other BSD’s)
ftp://ftp.openbsd.org/pub/OpenBSD/patches/3.4/i386/006_ibcs2.patch (same as other BSD’s)
And a lot of local and remote DoS vulnerabilities. I’m not sure what’s worse, a remote DoS or a local root compromise. I guess it differs per situation. I won’t even start about Windows, because i already provided a nice URL earlier and it’s a joke anyway.
Crontab is part of vcron aka Vixie Cron by Paul Vixie. Your own reference to the manpage is indeed a good one:
“crontab is the program used to install, deinstall or list the tables used to drive the cron(8) daemon in Vixie Cron.”
Futher on:
“STANDARDS The crontab command conforms to IEEE Std1003.2-1992 (“POSIX”). This new command syntax differs from previous versions of Vixie Cron, as well as from the classic SVR3 syntax.”
Congratulations, you just proofed the POSIX standard is insecure!
Paul Vixie’s / ISC’s software is software i’d rather not touch (anything by ISC: ISC-DHCPD, BIND, VCron, …) and somehow, strangely, we started “measuring kernels” only in this Microsoft Windows thread.
Anyway, who cares a rat ass. My points were 1) Software monoculture is a Bad Thing (even if it was regarding the Linux kernel, so blabla with your zealotry) 2) Microsoft is slow regarding patches, despite them claiming otherwise with “facts” regarding their security policy. I don’t see how these have been thrown away.
If i were Microsoft i’d hire people to spread FUD about competitors and in the meantime create a hardware layer which protects the insecure software layer! (:
http://www.pine.nl/press/pine-cert-20030901.txt
is the correct URL for the 5th bug in the FreeBSD kernel, which resides in (2) section of manuals and is a system call.
The other one is a similair bug, and is slighly older than 12 months; this one ain’t.
Well, Bascule…? The FreeBSD kernel is still ubersecure because of this, or not? …
*sigh* I don’t know why I’m continuing with
Me: You still haven’t mentioned what distribution you are running.
You: That doesn’t matter as much as “what cron do you use?”
vixie-cron
It *really does* matter, and if you actually took the time to read man crontab you would realize this… the description you give for the behavior of cron.allow and cron.deny is not default for the majority of Linux systems deployed which utilize vixie cron. The behavior of these files is described in man crontab:
If the /etc/cron.allow file exists, then you must be listed therein in order to be allowed to use this command. If the /etc/cron.allow file does not exist but the /etc/cron.deny file does exist, then you must not be listed in the /etc/cron.deny file in order to use this command. If neither of these files exists, then depending on site-dependent configuration parameters, only the super user will be allowed to use this command, or all users will be able to use this command.
For standard RedHat and Debian systems, all users may use the crontab command.
From your earlier post:
You CANNOT setup a cron job unless you are root on my machine and THIS IS THE DEFAULT CONFIGURATION.
Perhaps this is the default configuration on your distribution, but for some reason you’re still reluctant to even mention what that is. It certainly is not the standard behavior of cron.
*sigh* And it continues… I don’t even know why I bother replying…
I’m currently not even behind a computer with Linux, instead i’m using something entirely different. I’m wondering, why flame when you have such good arguments?
Because I get aggrivated when I receive such poor arguments in response
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-04:02…
^^^ System call input validation vulnerability resulting in a system level compromise. That’s 1
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-03:17…
^^^ Cannot be used to active a system level compromise. You’re still at 1.
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-03:10…
^^^ Requires the kernel be recompiled with IBCS support, but that doesn’t matter because it’s not a system level compromise. You’re still at 1.
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-03:09…
^^^ Possible system level compromise in FreeBSD 5.x only. That’s two.
I thought I made it clear my beef with Linux was the number of system level compromises in kernel code. Certainly these other exploits are breeches of kernel/userspace separation, but only two of them can be used to gain complete control of the system, and only one is relevant to a stable kernel.
And a lot of local and remote DoS vulnerabilities. I’m not sure what’s worse, a remote DoS or a local root compromise. I guess it differs per situation.
I think you should ask the SAs of Debian’s and Gentoo’s servers. A DoS usually causes no permanent damage, whereas a system level compromise means you’ll probably be spending several hours with the Coroner’s Toolkit recovering data off your compromised systems.
Congratulations, you just proofed the POSIX standard is insecure!
Allowing users to have crontabs is a security versus usability concession made by virtually every deployed *IX system in existance.
However, someone with a system clearly deviant from a standard configuration was insisting that disallowing users from editing crontabs is “THE DEFAULT CONFIGURATION“… as to the default configuration for what I’m not certain… perhaps his mystery distribution which he still hasn’t mentioned.
Anyway, who cares a rat ass. My points were 1) Software monoculture is a Bad Thing
Bad for security perhaps. Good for those of us who like to get things done with our computer and like one platform that all applications we use on a daily basis to run on.
I wouldn’t feel bad about dumping Windows for Linux entirely as soon as it can run Cubase, Reason, Logic, Painter, and a handful of other applications I use fairly frequently. But obviously, this probably isn’t going to happen any time soon… at least before I get a Mac desktop.
Microsoft is slow regarding patches, despite them claiming otherwise with “facts” regarding their security policy. I don’t see how these have been thrown away.
No argument in here. In this case the bug had no public disclosure and wasn’t being exploited in the wild, so Microsoft probably didn’t feel a compelling need to address the vulnerability immediately after its discovery. As to how Microsoft would’ve responded if the vulnerability were being exploited in the wild I certainly can’t say… they have a pretty spotty record in that department.
http://www.pine.nl/press/pine-cert-20030901.txt
Wow, that does make three in a year (since the vulnerability was fixed)… except only two in -STABLE. Well, I’m not going to nitpick… you proved me wrong, congratulations.
“Perhaps this is the default configuration on your distribution, but for some reason you’re still reluctant to even mention what that is. It certainly is not the standard behavior of cron.”
Anacron, doesn’t use crontab.
“Because I get aggrivated when I receive such poor arguments in response
”
Oh, but please, i run FreeBSD too! Please don’t flame me!1!11!!!
“Cannot be used to active a system level compromise. You’re still at 1.”
And:
“Such memory might contain sensitive information, such as
portions of the file cache or terminal buffers. This information might be directly useful, or it might be leveraged to obtain elevated privileges in some way. For example, a terminal buffer might include a user-entered password”
“^^^ Requires the kernel be recompiled with IBCS support, but that doesn’t matter because it’s not a system level compromise. You’re still at 1.”
Childish arguments this “standard” and “secure by default” stuff is. Because regarding Linux that Ptrace only worked if the USB drivers were existing. Well i assure you a sane server i admin does not have that enabled (and included earlier mentioned PaX). And what’s default per _distribution_? Differs. So that’s hard to compare in an objective way.
Also:
“Such memory might contain sensitive information, such as portions of the file cache or terminal buffers. This information might be directly useful, or it might be leveraged to obtain elevated privileges in some
way. For example, a terminal buffer might include a user-entered password.”
Same as the earlier which according to you doesn’t count. Then why doesn’t it? It sure is harder to exploit, but not impossible at all.
“I think you should ask the SAs of Debian’s and Gentoo’s servers.”
Only Debian (and Savannah), and that was both because of a local user who compromised his/her password. Gentoo was merely a mirror which wasn’t only for Gentoo, and it was due to rsync (has nothing to do with the Linux kernel).
“A DoS usually causes no permanent damage, whereas a system level compromise means you’ll probably be spending several hours with the Coroner’s Toolkit recovering data off your compromised systems.”
Only if the cracker has local access whereas a remote DoS can be done by “a lot more malicious internet users” which is exactly what i meant with the differs per situation. You’re perfectly right in the case the malicious user/cracker has local access and also remote for the DoS; then the local access is far more dangerous.
“Allowing users to have crontabs is a security versus usability concession made by virtually every deployed *IX system in existance.”
And even with that off, stuff like ~/.profile is a prime target.
“However, someone with a system clearly deviant from a standard configuration was insisting that disallowing users from editing crontabs is “THE DEFAULT CONFIGURATION”… as to the default configuration for what I’m not certain… perhaps his mystery distribution which he still hasn’t mentioned.”
If vcron is enabled i think you’re right. Fcron too btw. Anacron not. I did find a difference regarding at/atd. On Debian:
“An empty /etc/at.deny means that every user is allowed use these commands, this is the default configuration.”
On FreeBSD:
“If /var/at/at.allow does not exist, /var/at/at.deny is checked, every username not mentioned in it is then allowed to use at.
If neither exists, only the superuser is allowed use of at. This is the default configuration.”
FreeBSD rocks!!!11!!1
Gentoo for example doesn’t install vixie’s cron / vcron by default:
http://www.gentoo.org/doc/en/gentoo-x86-install.xml#doc_chap17
(scroll up a bit)
As for Microsoft i’ll just agree regarding this bug, the facts indeed are just like that. But not by definition regarding the loads of other ones, and i think a bug which is not “in the wild” but known should be fixed as soon as possible. Pro-active security is what OpenBSD calls that.
I also tend to agree with the programs stuff, though i’d like to see analysis regarding emulators, VM’s and certain programs, like Reason, CuBase, and more…
Wait a few months when an exploitation is discovered and suddenly everybody is saying, “OMG WHY NOBODY TELLING US THIS THINGS BEFORE! HOW TO FIXING IT?!” I seem to recall this happening not too long ago, 16th August or, something like that ;0) Hopefully the affected users have wised up and will actually follow the advice being given this time around. I remember the HUGE mess Johnson Controls (I work for them, so they’re pretty much the only corporate example I can give) had patching that up.
Or, alternatively, I could be reading into this thing completely wrong and arse backwards and all that.
Of course Kazaa is insecure by it’s very nature so that’s not a very fair example to use.
But using “Run As” only runs the selected application as admin the system on the whole is still running with limited priviliges, as I understand it.
Bottom line here, folks…
We’re sitting on a fortnight of machines sending MyDoom copies to everyone. We’ve seen overall slowdowns in net performance since it began, and that is ongoing.
Look at the number of worms, trojans and viruses we’ve seen over the past year. Look at examples such as Code Red, Nimda, and Slammer (which spread worldwide in 10 minutes and took down University networks, institutions, military installations and all net access for South Korea!).
Now look at the BSDs and Linux. In terms of network appliances and servers, Linux and BSDs are by far the majority of static-ip and long-term connected machines. If you wanted to do serious damage and cause problems, you’d attack them. You’d want to attack Apache especially, with close to 70% web server market share. Get that right and the amount of site defacements you could produce would be huge! In short, Linux and BSDs are a more desirable target for attack, and yet that isn’t happening.
So, look at the evidence. Look at which target is more desirable, and which one is more exploited.
Your ball.
I actually have to agree with you, i dont post too much on here , mostly its just reading thru, jumping over the troll messages etc. But it is true that the DESIREABLE targets are *nix machines whihc are largely unaffected in the sense of breaking and hacking. Yes there are the defacers that use rootkits or “exploit” a misconfigured server. however generally speaking the attacks go “against” home users windows machines…. why? BECAUSE they are by default so poorly configured and its so easy to lull windows users to opening an attachment. about the crontab, crontab -e works fine on this Suse 9 x86_64 box as a user, HOWEVER could you please tell me which mail client in linux will AUTO EXECUTE executables (binaries)? if you have the mime extensions set up it will openthe referring program but even that still has to be shown to me that it will then execute a script in the background. what about all the different versions of libraries etc?….
not trying to troll, just looking for info.
btw, anone got any link about a slackware release of x86_64? Suse is not my thing really….
No technical detail in the article whatsover. What is the flaw exactly, or even vaguely?
Perhaps this is the default configuration on your distribution, but for some reason you’re still reluctant to even mention what that is. It certainly is not the standard behavior of cron.
I don’t think you get it. As a poster said before, software monoculture is a bad thing. There are various distributions with various setups that are all different. So you can post about how lax security is within Linux but you are wrong. You are not even talking about Linux, you are talking about a certain OS with some crappy default configuration. The fact remains that I would not be affected by your little example, not because I changed anything, but because of the default configuration on my OS.
Perhaps this is the default configuration on your distribution, but for some reason you’re still reluctant to even mention what that is. It certainly is not the standard behavior of cron.
That’s funny because the manpage you quoted states that there is no standard behaviour. It can be one or the other.
Windows is easy to use that is good, but MS assums the users are stupid, & they hide the more advances stuff from us.
They tied IE into the OS, so when you use windows you use IE.
Since IE is tied into the os, an IE exploit is a OS exploit.
That’s funny because the manpage you quoted states that there is no standard behaviour. It can be one or the other.
That’s funny because allowing users to edit their crontabs is the default behavior of RedHat, Debian, FreeBSD, OpenBSD, NetBSD, Solaris, Irix, and HP-UX…
But not your mystery distribution, whatever that is.
Windows, with a secruity flaw!? No! I am shocked.
The sad part is it took them 200 days from the discovery of the flaw to the time they issued a patch, thats ridiculous. Sadly people pay for this software.