Re: If Macs have no spyware....

On Fri, 04 Nov 2005 19:40:59 -0700, GreyCloud <mist@xxxxxxxxxxx>
wrote:

>Josh McKee wrote:
>
>> On Fri, 04 Nov 2005 16:51:30 -0700, Steve Carroll <noone@xxxxxxxxxxx>
>> wrote:
>>
>>
>>>In article <0spnm1lhgsnf46calhelj1hkeqah9s21oq@xxxxxxx>,
>>>Josh McKee <jtmckee@xxxxxxxxxxxxxxx> wrote:
>>>
>>>
>>>>On Fri, 04 Nov 2005 14:26:22 -0700, Steve Carroll <noone@xxxxxxxxxxx>
>>>>wrote:
>>>>
>>>>
>>>>>In article <isigm1povia9sui23fi5vdv9br0f9nmavt@xxxxxxx>,
>>>>>Josh McKee <jtmckee@xxxxxxxxxxxxxxx> wrote:
>>>>>
>>>>>
>>>>>>On Tue, 01 Nov 2005 21:57:29 -0700, GreyCloud <cumulus@xxxxxxxx>
>>>>>>wrote:
>>>>>>
>>>>>>
>>>>>>>Josh McKee wrote:
>>>>>>>
>>>>>>>>On Tue, 01 Nov 2005 16:22:00 -0700, GreyCloud <cumulus@xxxxxxxx>
>>>>>>>>wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>>Josh McKee wrote:
>>>>>>>>>
>>>>>>>>>>On Mon, 31 Oct 2005 16:22:53 -0700, GreyCloud <cumulus@xxxxxxxx>
>>>>>>>>>>wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>Josh McKee wrote:
>>>>>>>>>>>
>>>>>>>>>>>>On Sun, 30 Oct 2005 12:45:45 -0700, GreyCloud <cumulus@xxxxxxxx>
>>>>>>>>>>>>wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>Josh McKee wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>On Sat, 29 Oct 2005 13:53:45 -0600, GreyCloud
>>>>>>>>>>>>>><cumulus@xxxxxxxx>
>>>>>>>>>>>>>>wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>Josh McKee wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>Did I cut out something that you thought was important and
>>>>>>>>>>>>>>>>should have
>>>>>>>>>>>>>>>>been addressed? Since we're in agreement that OS X is
>>>>>>>>>>>>>>>>susceptible to
>>>>>>>>>>>>>>>>malware I didn't see any point in addressing the rest of
>>>>>>>>>>>>>>>>what
>>>>>>>>>>>>>>>>you had
>>>>>>>>>>>>>>>>written.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>Typical wintroll perceptions of other imagined problems in
>>>>>>>>>>>>>>>other o/ses.
>>>>>>>>>>>>>>>Only windwoes has problems of significant magnitude.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>lol. Says the loser who claims that "OS X client doesn't have
>>>>>>>>>>>>>>Apache
>>>>>>>>>>>>>>installed".
>>>>>>>>>>>>>
>>>>>>>>>>>>>Says the moron that thinks XP is secure.
>>>>>>>>>>>>
>>>>>>>>>>>>See the difference between you and I is that my claims are
>>>>>>>>>>>>supported
>>>>>>>>>>>>in fact. Yours, well, they're not supported at all.
>>>>>>>>>>>
>>>>>>>>>>>Hardly. Your facts are erroneous and unsubstantiated.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>Guffaw!!!
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>I thought you were a knowledgable foe. But it's become
>>>>>>>>>>>>>>apparent
>>>>>>>>>>>>>>that
>>>>>>>>>>>>>>you're no better than the rest of the zealots.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>So sayeth the retarded Wintroll named Josh.
>>>>>>>>>>>>
>>>>>>>>>>>>Ah. The personal attack. A clear admission that I have bested
>>>>>>>>>>>>you.
>>>>>>>>>>>
>>>>>>>>>>>Guffaw!! Only in your dreams, wintroll.
>>>>>>>>>>>I've spotted you for what you are. A Phoney.
>>>>>>>>>>>You do not advocate for the mac, but are a M$ apologist.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>You're a Mac Advocate??
>>>>>>>>>>>>
>>>>>>>>>>>>Yep.
>>>>>>>>>>>
>>>>>>>>>>>Liar.
>>>>>>>>>>
>>>>>>>>>>With "arguments" like that there's no reason to continue trying to
>>>>>>>>>>hold a rational debate with you. I've got better things to do than
>>>>>>>>>>argue with someone who can do no better than call their opponent
>>>>>>>>>>names. If you decide that you're willing to have a mature discussion
>>>>>>>>>>perhaps we can pick this up in the future. Until then I'm bored with
>>>>>>>>>>your childish posts.
>>>>>>>>>
>>>>>>>>>You act like the fool that you've made yourself be.
>>>>>>>>>First you yammer about being a Mac advocate, then bad mouth
>>>>>>>>>me for dumping XP in favor of a Mac.
>>>>>>>>
>>>>>>>>To be clear: I'm not "bad mouthing" you for dumping XP in favor of the
>>>>>>>>Mac.
>>>>>>>>
>>>>>>>
>>>>>>>Oh? Wasn't it you that said I couldn't run XP Pro and so
>>>>>>>cut and run??
>>>>>>
>>>>>>I recall saying that you appear to be incapable of using Windows and
>>>>>>using it securely. But that doesn't mean that I am against your having
>>>>>>bought a Mac to replace it.
>>>>>>
>>>>>>What I disagree with is your blaming Windows for your ineptitude.
>>>>>
>>>>>Then you're also blaming the millions and millions and MILLIONS of users
>>>>>who have the same problem along with him... to the tune of billions and
>>>>>billions and BILLIONS of dollars, right? Great way to treat a customer
>>>>>base... blame them for a myriad of security problems. By the way, have
>>>>>you gotten that list together yet? You know the one... it'll contain
>>>>>multiple reasons why OSX doesn't have things like malware. Or will you
>>>>>be switching back to your original theme that no one is interested in an
>>>>>OS with so small a marketshare?
>>>>
>>>>Perhaps you'd be willing to take me up on my challenge? If I recall
>>>>correctly you live nearby making the challenge that much easier. And
>>>>it would address GreyClouds concerns. I'll even buy you lunch. Deal?
>>>>
>>>>Josh
>>>
>>>What has your challenge to do with the fact that millions and millions
>>>of users display this same sort of "ineptitude"?
>>
>>
>> So it's your opinion that Windows' problem with malware if the result
>> of inept users?
>
>Standard wintroll response.

Note the question mark at the end of my words. That means I'm asking a
question and not making a statement.

Are you going to take me up on my challenge or not?

Josh


>Make the end luser look responsible for crappy o/s design.
>
>http://www.theinquirer.net/?article=11108
>
>THAT THE Blaster worm should spread as rapidly as it did was testament
>to one thing only, the poor security in Microsoft's software.
>
>In the first few months of last year Microsoft spent about eight weeks
>in what was reportedly an intense effort to improve the security of
>their software. And what a joke that turned out to be, because within a
>just few months we were seeing security alerts about Microsoft products
>that had supposedly been thoroughly checked and corrected.
>
>These statements of 2002 were not the first time that Microsoft has
>declared the problem solved and buffer overflow banished. Back in
>September 2001 Jim Allchin, a Microsoft vice president, declared that
>this problem had been stamped out in Windows XP. Supposedly Microsoft
>had made a complete code review of its operating system and removed all
>the buffers which could overflow.
>
>Microsoft has had more than 15 years to get it right and it still cannot
>create a secure operating system. In fact in 2002 Windows had the
>dubious honour of accounting for 87% of all virus infections reported to
>the Australian office of the Sophos anti-virus group. This came on top
>of about 130 vulnerabilities that were reported for Windows during the
>year 2000, which is an average rate of more than one every three days.
>
>Given this kind of track record from Microsoft I am quite surprised that
>in jurisdictions with strong consumer laws there has never been a class
>action against Microsoft for selling poor quality software. Other
>operating systems have achieved far better security and have done so
>since their very early releases, so why is Microsoft unable to?
>
>As for secure operating systems, ask IBM users about the security of
>their operating systems prior to AIX which itself introduced the usual
>Unix problems. Or ask OpenVMS users about its security. Its bug list is
>still in the low double digits after about 30 major and minor versions
>in its 25 years, which is a sharp contrast to Microsoft's 130 problems
>in year 2000 alone!
>
>OpenVMS is even more relevant to Microsoft because about 1989 it
>acquired about 20 software engineers from Digital's cancelled Prism
>project which was developing an operating system called Mica. These
>engineers were the designers for Microsoft's NT and borrowed a large
>number of concepts from OpenVMS, but unfortunately the security concepts
>were not included. Was it a matter of meeting release deadlines,
>potential breakage of other code or keeping third party software houses
>happy? We will probably never know.
>
>Microsoft relies on the users to apply the stream of patches for Windows
>but many users are unaware of the patches or where to find them, and
>they are often reluctant to download large patches which can take hours
>over a dialup line. The frequency can be overwhelming and some users
>just ignore any problems that do not directly affect them. Microsoft's
>attitude seems to be so what if the virus mail bombs other users, so
>long as no damage happens to my system.
>
>And wrapped around all this is the quite reasonable argument that if
>Microsoft cannot produce secure product releases then its ability to
>produce secure patches just as suspect.
>
>In recent years Microsoft has had the gall to receive an award for its
>security from the Department of Defense (perhaps the first award for
>"lowering the bar" in many years) and another reward for the manner in
>which it created tools to allow users the ability to automatically patch
>their software versions. It is simply beyond a joke.
>
>In my opinion, the fundamental problem is that the basic architecture of
>Windows has two fatal flaws in its memory management and while these
>remain in the software the ad hoc patches will never be enough to make
>Windows a secure operating system.
>
>Fundamental Problems with the Stack
>The first problem is the same as that which has bugged the Unix world
>for many years, the notorious "buffer overflow problem".
>
>This occurs when a program attempts to write data into a space that is
>not large enough for it. Within a routine there may be references to an
>array that actually point beyond the end-point of that array and point
>at some other data. Using this data at some point in the processing
>would be invalid, and writing new data into those memory locations would
>corrupt any data that exists there.
>
>Character strings are particularly notorious for this, especially those
>where the length is not defined and is only discovered by finding a null
>character. If that last character was overwritten by other data, the end
>of the string would not be found and the processing would continue.
>
>These problems are bad enough when dealing with data in the one routine
>but when the data exists on the stack, it can cause very large problems.
>
>The "stack" is a control structure which is used to manage the transfer
>of control to functions or other routines that are called by a program.
>(Some people confuse this with the "heap" which stores temporary
>variables but essential difference is that the stack contains control
>data as well as user data and is managed largely by the operating
>system, whereas the heap holds user's temporary data which is accessed
>by the program making calls to system routines.)
>
>When a function is called, the arguments are written to the stack along
>with a pointer to the next instruction in the current code. On returning
>from that function the operating system uses the pointer to discover the
>next instruction to be executed.
>
>The vulnerability in the stack exists because in C, C++ and a number of
>other languages, the value of the arguments is written onto the stack
>and the length of these data items is never checked. It is very simple
>for the code in the function to replace these argument values with
>values of greater length and in doing so corrupt other data on the
>stack, including the pointer to the next instruction.
>
>It is as simple as passing an array or character string of a certain
>length to a function but within the function using it as longer array or
>string by writing some additional bytes onto the end of it.
>
>This problem is fundamental to any language and operating system where
>data of variable length is written to the stack and no check is ever
>made on the length of the data items being used.
>
>Fortran 77 and a few other languages almost always only write the
>address of a data item to the stack and these addresses are of known
>length. I believe that there are also some operating systems will
>monitor the length of the data items to ensure that no corruptions can
>occur.
>
>To take advantage of this vulnerability of stack corruption all that one
>has to do, by accident or design, is replace the execution pointer that
>was written onto the stack with a new value. On return from the function
>the operating system will access what it believes to be the stored
>program counter and proceed to execute the code at the new location.
>
>One further point here is that even the simplest call of another
>function can cause the corruption of the stack. Email headers of great
>length have caused this corruption and even access strings for remote
>procedure calls.
>
>Problem of Controlling Access to Memory
>This problem with stack handling would be an irritation rather than a
>real danger if it all it did was cause the software or the operating
>system to crash. Unfortunately the second problem turns this into a very
>nasty vulnerability, one that can permit viruses to execute and cause havoc.
>
>This second problem is the crude manner in which Windows - and indeed
>some forms of Unix - fail to properly control access to memory. In both
>systems it is very easy to write data into memory and then execute it.
>In early versions of these operating systems there were chronic
>vulnerabilities that led to some very serious viruses and worms.
>
>Windows XP has finally implemented some controls on the access to memory
>and according to Microsoft's web pages, it is the responsibility of
>programmers to specify one of the following values when allocating or
>protecting a page in memory.
>
>PAGE_EXECUTE
>PAGE_EXECUTE_READ
>PAGE_EXECUTE_READWRITE
>PAGE_EXECUTE_WRITECOPY
>PAGE_NOACCESS
>PAGE_READONLY
>PAGE_READWRITE
>PAGE_WRITECOPY
>
>Despite all the known problems with allowing a user to write data to
>memory and then have the potential to execute it, Microsoft has
>explicitly allowed this as an option that is under the control of the
>software developer. I am not sure that I want to ask what the default
>state is because I am aware that compatibility wuld be seen as desirable.
>
>It might appear that the solution to this problem on Windows is very
>simple and all that is required is to remove the PAGE_EXECUTE_READWRITE
>option and to enforce compilers and linkers to use the appropriate
>protection by default. The reality is that certain Microsoft Office
>products have been known to dynamically create code and then execute it,
>in a manner known as "trampolining". Rather than modify its Office
>software so that this did not take place, Microsoft seems to have chosen
>to put the IT world at risk.
>
>A Volatile Combination
>Put the problem of buffer over-run corrupting the instruction pointer
>with the ability to execute instructions that have been written to
>memory as "data" and the extreme vulnerability of the situation becomes
>obvious.
>
>All that it requires is for those new instructions to copy files across
>the network to this machine, or to delete files, or to modify system
>settings, or to use system routines to perform some function such as
>send mail to other systems and all hell breaks loose.
>
>Some claim that it is rather more difficult to discover the memory
>location that needs to be written in place of the correct execution
>pointer but I believe that all it really requires is for the malicious
>code to contain a known string of characters, perhaps normal ASCII
>characters which are bypassed during execution by a "jump" statement,
>and to search through memory until that string is discovered.
>
>Attitudes to the Problem
>The lack of proper control of the stack used in Windows has spawned a
>number of third-party solutions, which attempt to enforce some kind of
>check. Most do not prevent the buffer overflow from occurring but
>enforce checks to take place as control is returned to the calling routine.
>
>One common solution is to use "canary" data, a single data item that is
>written to the stack to separate the arguments from the execution
>pointer. As the control is returned a check is made as to whether the
>canary data contains the expected value and if it does not, the
>execution pointer cannot be guaranteed and the program terminates.
>
>This seems all very well but, depending on the platform, if the called
>routine was malicious, it could examine the stack for the canary data
>and take steps to ensure that the same value is written to that
>location. Thus, in a single step, the protection mechanism is rendered
>useless and the user's confidence in it has been entirely misplaced.
>
>Unix users have no cause to smirk at these deficiencies of Windows
>because most Unix variants suffer from the same problem, including those
>that are regarded as the more secure.
>
>Earlier this year the folk responsible for OpenBSD made a big statement
>about how they had made changes to their code, which according to a CNet
>report, would "make causing a buffer overflow extremely difficult, if
>not impossible." They were, in effect, admitting that OpenBSD had been
>suffering from this problem.
>
>They went on to remark that this was "?a software issue that has been
>plaguing security experts for more than three decades." but this comment
>is incorrect.
>
>The OpenBSD solution involved a three-pronged approach. They were about
>to implement the use of a data "canary", they would randomised the
>memory location for the stack and to use CNet's words, they " found a
>way to hack the BSD file system and divide main memory into a writable
>portion and an executable portion".
>
>As I mentioned above, the use of a data canary may be no guarantee of
>security and the randomised location is of limited value if the
>malicious code has a method of searching memory to find a specific
>string of characters and from that deducing the location.
>
>The division of memory into writable and executable portions is
>certainly nothing novel and I am very surprised that this is seen as an
>innovation in the general Unix world. As I mentioned above, Windows XP
>has this division and has introduced a limited kind of memory protection.
>
>BSD might be introducing it now but OpenVMS had even stronger and more
>flexible protection on regions of memory from its very first release in
>1979. If my memory serves, OpenVMS wasn't even the first operating
>system from Digital Equipment to have this feature but inherited it from
>the PDP machines running RSTS, RSX or RT-11 and ironically it was these
>PDP machines that were the first platform for Unix.
>
>Some Solutions
>The solution that Microsoft has been trying to apply involves the use of
>software packages to identify vulnerabilities. It also appear to be
>experimenting with different languages, perhaps in the hope of finding
>one which offers its programmers a better chance of fixing the problem
>or avoiding it altogether. Both seem to be rather a waste of time and
>effort when all it really requires is to use correct concepts in the
>operating system and compilers.
>
>On the matter of memory regions and their protection it is absolutely
>clear that this technique needs to be applied and done so in a very
>strict fashion with none of the stupidity of EXECUTE_READWRITE. I can do
>no better than suggest that Windows and Unix take a good look at how
>OpenVMS handles these matters because it has the most effective system
>that I am aware of.
>
>The method used by OpenVMS is one of separating the virtual memory into
>regions, each with their own protection. At execution time the various
>program sections (PSECTs) are loaded into one of these regions into
>orderly and defined areas, applying the protections specified for each
>PSECT as it does so. Thus data is separated from executable code.
>
>It is similar to the protection offered by Windows XP, which is not
>surprising since NT arrived on the scene but the important difference is
>that PSECT protections are set by default and the programmer must
>explicitly modify them for special circumstances.
>
>Now this introduction of proper memory access controls is all that is
>required to prevent the introduction and execution of malicious code but
>it does not solve the problem of an overflowed buffer corrupting the
>call stack.
>
>A reliable solution to this second problem can probably only come about
>by altering the manner in which the stack is used.
>
>One possible option is to change the order in which the data items are
>written to the stack so that the return address pointer and the pointer
>to the previous call frame are written before the parameters. This means
>that any buffer overflow on the function arguments would not corrupt
>these data items but may simply attempt to write beyond the end of the
>stack.
>
>Another option is to write the parameters to the heap, not the stack and
>on the stack simply write their data length and their address on the
>heap. This would enable them to be used and if they were returned to the
>calling routine, it would be a simple matter to copy the specified
>number of bytes from the specified heap address into a known location
>for the calling routine. Buffer overflow on the heap would still quite
>possible but these would be impossible to eradicate without fundamental
>changes to several programming languages.
>
>Both options would require changes to compilers so that the stack was
>used in a way that made it immune to the vexatious problem of buffer
>overflow corrupting the stack. One would imagine though that these
>changes and the very small amount of additional processing would be a
>small price to pay in order to avoid these problems.
>
>>
>>>Proving I can't hack in won't mean too much and I think you know that,
>>>I don't claim to be that computer savvy.
>>
>>
>> It's not a hacking challenge.
>>
>> I see that you're not willing to put your money where your mouth is
>> either. Hell, you're not even willing to put MY money where your mouth
>> is.
>>
>
>
>Still a strawmans argument.

.

Relevant Pages

  • Re: If Macs have no spyware....
    ... First you yammer about being a Mac advocate, then bad mouth me for dumping XP in favor of a Mac. ... Supposedly Microsoft had made a complete code review of its operating system and removed all the buffers which could overflow. ... the fundamental problem is that the basic architecture of Windows has two fatal flaws in its memory management and while these remain in the software the ad hoc patches will never be enough to make Windows a secure operating system. ... These problems are bad enough when dealing with data in the one routine but when the data exists on the stack, it can cause very large problems. ...
    (comp.sys.mac.advocacy)
  • Re: I want to learn forth but...
    ... on each pass of the loop. ... deeper in the execution stack. ... memory, and the part I quoted gave another loop approach (cyclic ...
    (comp.lang.forth)
  • Denesting
    ... >From: robert spykerman ... memory or memory area. ... How big is this execution area going to ... >stack with perhaps a couple of stack items cached in registers... ...
    (comp.lang.forth)
  • Re: Heap vs Stack
    ... other memory area. ... Does any limit exist upto which a stack or a heap can grow. ... feature of the operating system on the platform. ...
    (comp.unix.programmer)
  • Re: A quit strange coredump
    ... Depends on the operating system. ... however I could only allocate about ... 110M in the stack. ... If you want to know how much more memory you could allocate, ...
    (comp.lang.c)