The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.
[EMAIL PROTECTED] (Timothy Sipples) writes: > The first thing to say is that Linux is Linux, so for anyone who still > thinks that Linux is somehow emulated on System z, it's not. When you run > Linux on the mainframe it's a 31-bit or 64-bit Linux kernel (and programs) > running native ESA/390 or z/Architecture processor instructions. lots of past posts discussing typical c language programming and execution ... resulting in lots of buffer related vulnerabilities. part of this is that implicit string and buffer lengths tend to be extremely prevelent in c programming styles, programmers make assumptions that no buffer operations will exceed the buffer target ... and these assumptions can be used by attackers http://www.garlic.com/~lynn/subpubkey.html#overflow at one point the majority of exploits (in c language environments) were length related. attackers would include machine executable instructions (would be tailored for the victim machine) in various incoming data ... and manage to contrive the processor to transfer to those instructions. the problem became so serious on many platforms that hardware countermeasure was introduced in the past couple years ... somewhat akin to 360 storage protection. however, instead of data store/fetch protection ... it is i-stream fetch protection. standard data store/fetch operations work ... but if the processor attempts to fetch instructions from the protected location there is a fault (as countermeasure to attackers introducing malicious instructions hidden in data streams and leverage short comings in data length handling). a past post mentioning hardware "no-execute" storage protection (with some web references) http://www.garlic.com/~lynn/2005.html#1 Buffer overruns trivial search engine use looking for references to various kinds of hardware support for no-execute will turn up lots more. however, the rise in the use of automatic scripting associated with many application environments has somewhat changed the exploits. this attack pattern was identified on the internal network in the 70s. lots of past posts about the internal network http://www.garlic.com/~lynn/subnetwork.html#internalnet note that scripting exploits tend to be machine architecture neutral since its tends to involved interpreted code. as various applications added support for automatic execution of embedded scripts in data files (email, etc) ... the ratio changed. At one point studies found exploits to be broken down: 1/3rd automatic scripting, 1/3rd (still) buffer related, and 1/3rd social engineering (manipulating humans to divulge sensitive information). social engineering has since expanded into things like phishing. recent post on the topic of identifying and categorizing exploits and vulnerabilities http://www.garlic.com/~lynn/2006p.html#43 Slow-Going For Next-Generation Threat-Scoring System older post looking at categorizing exploits http://www.garlic.com/~lynn/2004e.html#43 security taxonomy and CVE and slightly more recent post discussing the categorizing of exploits http://www.garlic.com/~lynn/2005b.html#20 Buffer overruns and lots of collected posts on the subject of exploits, vulnerabilities, threats and fraud http://www.garlic.com/~lynn/subpubkey.html#fraud ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
