But Kristensen noted that, with the new update, only a few of the 44 vulnerabilities are of great concern. He also said that 25 percent of the patches involve older vulnerabilities that have yet to lead to exploit code being developed by attackers. Still, Secunia is rating the overall update as "highly critical."
Apple declined to comment on the vulnerabilities and referred all questions to its security update.
The flaws affect Apple's Mac OS 10.3.9 and 10.4.2 operating system software and related server software.
Kristensen said that some vulnerabilities involving AppKit and Safari are critical.
AppKit, which is used to open RTFs (rich text files) and Word documents, has flaws that allow a remote attacker to create a malicious file that results in a buffer overflow. That in turn can lead to arbitrary code being executed on a user's system.
Apple, however, notes that only some applications use AppKit, and that Microsoft Word for Mac OS X is not vulnerable.
Flaws in Safari, meanwhile, can allow an attacker to bypass the browser's security checks and execute arbitrary commands, when the user clicks on a maliciously crafted rich text file.
Another flaw, a vulnerability in Apple's Sever Manager D, a modified version of Apache, is also being considered critical by some.
That flaw can result in a buffer overflow and remote execution of code by an attacker, with no user interaction, said Frank Nagle, assistant director of vulnerability aggregation for iDefense, a VeriSign company.
Although Apple lists other security flaws that could be exploited by a remote attacker, they are "less critical," according to Secunia.
For example, two vulnerabilities in Apache 2 could be exploited by a remote attacker to either bypass security restrictions or launch a denial-of-service attack.
But Apple did not set Apache 2 by default, so it is less of an issue than it would be if the same vulnerabilities affected Apache 1.3, Nagle said.
from Microsoft advocates. While none of the code has been exploited by attackers (unlike MS's flaws) be prepared for the onslaught. Remember, that your best weapon is the truth against these trolls and they shall not stand! Yippy-kai-yay mother%(&^(!!!
Why haven't these "holes" been exploited like the MS ones that have?
Answer: There are only 4 Macs in the whole world connected to the internet....so it's not worth the effort to write an exploit. HA HA HA
Sorry, when you said to prepare for the flames I couldn't resist trolling and posting :):)
I like Macs. I have nothing against them. I am the first to admit that MSFT has a horrible security track record...Just had to drop in and push a few buttons. :)
Looks pretty quiet, perhaps the MS supporters aren't as vocal as the Mac crowd who would be all over this if it were patches to Windows being released.
Does that mean the MS supporters are less committed or that the Mac supporters need to be committed? :)
"While none of the code has been exploited by attackers (unlike MS's flaws)"
How does that make a difference? As is proven (again) by this article, both systems have flaws. So how is it Microsoft's fault that their flaws happen to be the most exploited? It makes perfect sense that the most used system would be the most attacked. Generally an attacker's goal is to cause as much damage and trouble as possible, and to do that, it makes sense to exploit the flaws found in the system that the majority of people are using, not the minority. If two products have flaws, one isn't automatically better than the other just because the most used of the two gets attacked.
from Microsoft advocates. While none of the code has been exploited by attackers (unlike MS's flaws) be prepared for the onslaught. Remember, that your best weapon is the truth against these trolls and they shall not stand! Yippy-kai-yay mother%(&^(!!!
Why haven't these "holes" been exploited like the MS ones that have?
Answer: There are only 4 Macs in the whole world connected to the internet....so it's not worth the effort to write an exploit. HA HA HA
Sorry, when you said to prepare for the flames I couldn't resist trolling and posting :):)
I like Macs. I have nothing against them. I am the first to admit that MSFT has a horrible security track record...Just had to drop in and push a few buttons. :)
Looks pretty quiet, perhaps the MS supporters aren't as vocal as the Mac crowd who would be all over this if it were patches to Windows being released.
Does that mean the MS supporters are less committed or that the Mac supporters need to be committed? :)
"While none of the code has been exploited by attackers (unlike MS's flaws)"
How does that make a difference? As is proven (again) by this article, both systems have flaws. So how is it Microsoft's fault that their flaws happen to be the most exploited? It makes perfect sense that the most used system would be the most attacked. Generally an attacker's goal is to cause as much damage and trouble as possible, and to do that, it makes sense to exploit the flaws found in the system that the majority of people are using, not the minority. If two products have flaws, one isn't automatically better than the other just because the most used of the two gets attacked.
This is a real company?? With a real purpose??? ? I've never heard of them before, and I don't expect to again - unless someone can tell me why I should.
This is a real company?? With a real purpose??? ? I've never heard of them before, and I don't expect to again - unless someone can tell me why I should.
Hmm, how soon one forgets the world's very first computer virus was actually written for A Mac, and then rapidly morphed to the more popular M$Windows systems. But still, these fans omit the fact that the initial release version, should not have contained so many fatal errors and flaws in the first place, as always you pays your money and takes your choice.
Hmm, how soon one forgets the world's very first computer virus was actually written for A Mac, and then rapidly morphed to the more popular M$Windows systems. But still, these fans omit the fact that the initial release version, should not have contained so many fatal errors and flaws in the first place, as always you pays your money and takes your choice.
If OS X had the market share that windows has, there would be a lot of friggin virus's! 44 fixes! Holy crap. And with no auto-update feature the masses would really be in trouble.
If there is an autoupdate feature in OS X I am not aware of it because I do not care to shell out $500 for the lowest end mac that has crappy hardware and cant be upgraded.
You really don't know what you're talking about, do you? Do you? You post blah- blah but you lack a true grip on reality when slamming Apple's OS. You just repeat IT watercooler myths.
Grow up and educate yourself before you offer an opinion. Otherwise you will continue to sound silly.
Say early in 1981 on the venerable Apple ][(Mac's great then market dominating predecessor) a diskette, boot sector virus appeared called "elk cloner" (remember, the very first IBM PC (8088 4.77 MHz clock went on sale on August 12th , 1981 and the rest is history when the infant Tiawanese wanna be PC industry, went onto clone same and create the industry as we know today and Billy G's superfortune, and apple went from leader of the pack to the last runner on the block all within less than 5 years, for the 1984 all in one MAC had a minimum of three very fatal flaws(and even then virii for it abounded, which nobody can deny) Oh please Mr H. go on repeating the mistakes of history, don't let me stop you! For those who fail to heed the lessons of history, they are doomed to repeat them! Choices , choices choices!, it's your choice!
If OS X had the market share that windows has, there would be a lot of friggin virus's! 44 fixes! Holy crap. And with no auto-update feature the masses would really be in trouble.
If there is an autoupdate feature in OS X I am not aware of it because I do not care to shell out $500 for the lowest end mac that has crappy hardware and cant be upgraded.
You really don't know what you're talking about, do you? Do you? You post blah- blah but you lack a true grip on reality when slamming Apple's OS. You just repeat IT watercooler myths.
Grow up and educate yourself before you offer an opinion. Otherwise you will continue to sound silly.
Say early in 1981 on the venerable Apple ][(Mac's great then market dominating predecessor) a diskette, boot sector virus appeared called "elk cloner" (remember, the very first IBM PC (8088 4.77 MHz clock went on sale on August 12th , 1981 and the rest is history when the infant Tiawanese wanna be PC industry, went onto clone same and create the industry as we know today and Billy G's superfortune, and apple went from leader of the pack to the last runner on the block all within less than 5 years, for the 1984 all in one MAC had a minimum of three very fatal flaws(and even then virii for it abounded, which nobody can deny) Oh please Mr H. go on repeating the mistakes of history, don't let me stop you! For those who fail to heed the lessons of history, they are doomed to repeat them! Choices , choices choices!, it's your choice!
>...has flaws that allow a remote attacker to create a > malicious file that results in a buffer overflow. That > in turn can lead to arbitrary code being executed > on a user's system.
I see this statement all the time applied to UNIX systems. I don't think it's true. Buffers in UNIX programs are always allocated in a data segment (as opposed to a text segment where code lives). This includes the stack frames used for local procedural storage.
It is not even possible to write to the text segments of a program; UNIX in conjunction with the hardware MMU make sure that it can't happen -an attempt to do so will immediately fault the app.
By the same token, it is impossible to execute data in the data segment, unless the application calls a special function ::MakeDataExecutable() (at least on the Mac). If the programmer never calls ::MakeDataExecutable(), which is by far the norm, then you can overflow buffers all day long and it will NEVER cause any harm. It simply can't by definition. That is one of the inherent security features of UNIX and one of the big reasons it is virtually virus free.
I forgot to mention that executable code lives in text segments.
So to reiterate, executable code lives in text segments and can only be read and executed -never wriiten to. Buffers and all other data live in data segments, which can only be read and written -never executed. All of this is strictly enforced by hardware with immediate death to any and all violaters.
Hence data in a buffer, which by definition must be in the data segment -even if the buffer overflows, cannot be executed. Overflow or not.
You may be right that Mac OS X does not allow execution of code located on the stack, but Mac OS X systems still use library calls, which an attacker can redirect program flow into. Executing the sys_execve call to launch an instance of /bin/sh would be dangerous, given the right permissions, now wouldn't it?
So, you've either been misinformed, or you're making things up.
And furthermore, why would Apple bother releasing a patch for a security hole if there was no security hole?
>...has flaws that allow a remote attacker to create a > malicious file that results in a buffer overflow. That > in turn can lead to arbitrary code being executed > on a user's system.
I see this statement all the time applied to UNIX systems. I don't think it's true. Buffers in UNIX programs are always allocated in a data segment (as opposed to a text segment where code lives). This includes the stack frames used for local procedural storage.
It is not even possible to write to the text segments of a program; UNIX in conjunction with the hardware MMU make sure that it can't happen -an attempt to do so will immediately fault the app.
By the same token, it is impossible to execute data in the data segment, unless the application calls a special function ::MakeDataExecutable() (at least on the Mac). If the programmer never calls ::MakeDataExecutable(), which is by far the norm, then you can overflow buffers all day long and it will NEVER cause any harm. It simply can't by definition. That is one of the inherent security features of UNIX and one of the big reasons it is virtually virus free.
I forgot to mention that executable code lives in text segments.
So to reiterate, executable code lives in text segments and can only be read and executed -never wriiten to. Buffers and all other data live in data segments, which can only be read and written -never executed. All of this is strictly enforced by hardware with immediate death to any and all violaters.
Hence data in a buffer, which by definition must be in the data segment -even if the buffer overflows, cannot be executed. Overflow or not.
You may be right that Mac OS X does not allow execution of code located on the stack, but Mac OS X systems still use library calls, which an attacker can redirect program flow into. Executing the sys_execve call to launch an instance of /bin/sh would be dangerous, given the right permissions, now wouldn't it?
So, you've either been misinformed, or you're making things up.
And furthermore, why would Apple bother releasing a patch for a security hole if there was no security hole?
I certainly can't follow your logic. What part of the thread am I missing? All I am saying is that a buffer overflow cannot result in unauthorized code being executed in UNIX. Shouting at me, calling me "clueless" (extremely unprofessional behavior for a newsdotcom representative by the way) does not in any way refute the assertion.
The "you just don't know what you are talking about" argument" might be good enough for cable but somewhat lacking in a technical forum. Working in the ROM and kernel for 10 years on OS X and 20 years or so on OS 9 has given me some insight into how these things work.
I did not realize what kind of people were behind this organization, but I suppose I was too busy looking at the facts (sorry "trees") wasn't I?
I certainly can't follow your logic. What part of the thread am I missing? All I am saying is that a buffer overflow cannot result in unauthorized code being executed in UNIX. Shouting at me, calling me "clueless" (extremely unprofessional behavior for a newsdotcom representative by the way) does not in any way refute the assertion.
The "you just don't know what you are talking about" argument" might be good enough for cable but somewhat lacking in a technical forum. Working in the ROM and kernel for 10 years on OS X and 20 years or so on OS 9 has given me some insight into how these things work.
I did not realize what kind of people were behind this organization, but I suppose I was too busy looking at the facts (sorry "trees") wasn't I?
Google creates an animated doodle that features a boy, a girl, Google's search engine, and a jump rope. But might there be darker, more analytical, more troubling interpretations to this tale?
The Silicon Valley online payments startup grew by 1,000 percent last year and is hopeful it can repeat that level of growth this year. To do that, it's had to move away from its early friends-and-family roots and embrace small businesses.
Chamtech's spray-on antenna uses a nano material to provide a low-power boost to antenna range. The wireless-in-a-can product may some day bring an end to unsightly cell towers.
EnerG2 opens a plant to make an engineered carbon that will improve performance of energy storage devices and make storage for start-stop hybrid cars less expensive.
Perhaps you meant Mac OS X 10.3.9?
Perhaps you meant Mac OS X 10.3.9?
Answer: There are only 4 Macs in the whole world connected to the internet....so it's not worth the effort to write an exploit. HA HA HA
Sorry, when you said to prepare for the flames I couldn't resist trolling and posting :):)
I like Macs. I have nothing against them. I am the first to admit that MSFT has a horrible security track record...Just had to drop in and push a few buttons. :)
Does that mean the MS supporters are less committed or that the Mac supporters need to be committed? :)
How does that make a difference? As is proven (again) by this article, both systems have flaws. So how is it Microsoft's fault that their flaws happen to be the most exploited? It makes perfect sense that the most used system would be the most attacked. Generally an attacker's goal is to cause as much damage and trouble as possible, and to do that, it makes sense to exploit the flaws found in the system that the majority of people are using, not the minority. If two products have flaws, one isn't automatically better than the other just because the most used of the two gets attacked.
Answer: There are only 4 Macs in the whole world connected to the internet....so it's not worth the effort to write an exploit. HA HA HA
Sorry, when you said to prepare for the flames I couldn't resist trolling and posting :):)
I like Macs. I have nothing against them. I am the first to admit that MSFT has a horrible security track record...Just had to drop in and push a few buttons. :)
Does that mean the MS supporters are less committed or that the Mac supporters need to be committed? :)
How does that make a difference? As is proven (again) by this article, both systems have flaws. So how is it Microsoft's fault that their flaws happen to be the most exploited? It makes perfect sense that the most used system would be the most attacked. Generally an attacker's goal is to cause as much damage and trouble as possible, and to do that, it makes sense to exploit the flaws found in the system that the majority of people are using, not the minority. If two products have flaws, one isn't automatically better than the other just because the most used of the two gets attacked.
"Virus writers will be gone soo-nia,
because we're the company named Secu-nia,
we have no software or vaccu-nias,
because we are Secunia."
them before, and I don't expect to again - unless someone can tell
me why I should.
"Virus writers will be gone soo-nia,
because we're the company named Secu-nia,
we have no software or vaccu-nias,
because we are Secunia."
them before, and I don't expect to again - unless someone can tell
me why I should.
virus writer's tattered underwear. TRY to be relevant when you
post.
I can tell you never used Windows 1.0
virus writer's tattered underwear. TRY to be relevant when you
post.
I can tell you never used Windows 1.0
If there is an autoupdate feature in OS X I am not aware of it because I do not care to shell out $500 for the lowest end mac that has crappy hardware and cant be upgraded.
You post blah- blah but you lack a true grip on reality when
slamming Apple's OS. You just repeat IT watercooler myths.
Grow up and educate yourself before you offer an opinion.
Otherwise you will continue to sound silly.
If there is an autoupdate feature in OS X I am not aware of it because I do not care to shell out $500 for the lowest end mac that has crappy hardware and cant be upgraded.
You post blah- blah but you lack a true grip on reality when
slamming Apple's OS. You just repeat IT watercooler myths.
Grow up and educate yourself before you offer an opinion.
Otherwise you will continue to sound silly.
I wonder how many...43 maybe? :)
I wonder how many...43 maybe? :)
> malicious file that results in a buffer overflow. That
> in turn can lead to arbitrary code being executed
> on a user's system.
I see this statement all the time applied to UNIX systems. I don't
think it's true. Buffers in UNIX programs are always allocated in a
data segment (as opposed to a text segment where code lives).
This includes the stack frames used for local procedural storage.
It is not even possible to write to the text segments of a
program; UNIX in conjunction with the hardware MMU make sure
that it can't happen -an attempt to do so will immediately fault
the app.
By the same token, it is impossible to execute data in the data
segment, unless the application calls a special
function ::MakeDataExecutable() (at least on the Mac). If the
programmer never calls ::MakeDataExecutable(), which is by far
the norm, then you can overflow buffers all day long and it will
NEVER cause any harm. It simply can't by definition. That is one
of the inherent security features of UNIX and one of the big
reasons it is virtually virus free.
So to reiterate, executable code lives in text segments and can
only be read and executed -never wriiten to. Buffers and all
other data live in data segments, which can only be read and
written -never executed. All of this is strictly enforced by
hardware with immediate death to any and all violaters.
Hence data in a buffer, which by definition must be in the data
segment -even if the buffer overflows, cannot be executed.
Overflow or not.
So, you've either been misinformed, or you're making things up.
And furthermore, why would Apple bother releasing a patch for a security hole if there was no security hole?
> malicious file that results in a buffer overflow. That
> in turn can lead to arbitrary code being executed
> on a user's system.
I see this statement all the time applied to UNIX systems. I don't
think it's true. Buffers in UNIX programs are always allocated in a
data segment (as opposed to a text segment where code lives).
This includes the stack frames used for local procedural storage.
It is not even possible to write to the text segments of a
program; UNIX in conjunction with the hardware MMU make sure
that it can't happen -an attempt to do so will immediately fault
the app.
By the same token, it is impossible to execute data in the data
segment, unless the application calls a special
function ::MakeDataExecutable() (at least on the Mac). If the
programmer never calls ::MakeDataExecutable(), which is by far
the norm, then you can overflow buffers all day long and it will
NEVER cause any harm. It simply can't by definition. That is one
of the inherent security features of UNIX and one of the big
reasons it is virtually virus free.
So to reiterate, executable code lives in text segments and can
only be read and executed -never wriiten to. Buffers and all
other data live in data segments, which can only be read and
written -never executed. All of this is strictly enforced by
hardware with immediate death to any and all violaters.
Hence data in a buffer, which by definition must be in the data
segment -even if the buffer overflows, cannot be executed.
Overflow or not.
So, you've either been misinformed, or you're making things up.
And furthermore, why would Apple bother releasing a patch for a security hole if there was no security hole?
missing? All I am saying is that a buffer overflow cannot result in
unauthorized code being executed in UNIX. Shouting at me,
calling me "clueless" (extremely unprofessional behavior for a
newsdotcom representative by the way) does not in any way
refute the assertion.
The "you just don't know what you are talking about" argument"
might be good enough for cable but somewhat lacking in a
technical forum. Working in the ROM and kernel for 10 years on
OS X and 20 years or so on OS 9 has given me some insight into
how these things work.
I did not realize what kind of people were behind this
organization, but I suppose I was too busy looking at the facts
(sorry "trees") wasn't I?
previous thread. It ended up out here instead. Oh well.
missing? All I am saying is that a buffer overflow cannot result in
unauthorized code being executed in UNIX. Shouting at me,
calling me "clueless" (extremely unprofessional behavior for a
newsdotcom representative by the way) does not in any way
refute the assertion.
The "you just don't know what you are talking about" argument"
might be good enough for cable but somewhat lacking in a
technical forum. Working in the ROM and kernel for 10 years on
OS X and 20 years or so on OS 9 has given me some insight into
how these things work.
I did not realize what kind of people were behind this
organization, but I suppose I was too busy looking at the facts
(sorry "trees") wasn't I?
previous thread. It ended up out here instead. Oh well.