| PLEX86 | ||
Linux More Secure on System z
lots of past posts discussing typical c language programming and end ... 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 buttumptions that no buffer operations will exceed the buffer target ... and these buttumptions can be used by attackers 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) 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 buttociated 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 note that scripting exploits tend to be machine architecture neutral since its tends to involved interpreted code. Another BIG Mainframe Bites the Dust re: the future system project was going to have lots of stuff like that (as well as gobs of other stuff) ... and would... as various applications added support for automatic end 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 older post looking at categorizing exploits and slightly more recent post discussing the categorizing of exploits and lots of collected posts on the subject of exploits, vulnerabilities, threats and fraud
|
||||
Another BIG Mainframe Bites the Dust Alt Folklore Computers from Newsgroups The #1 Usenet Provider on the Internet
|
||||