Slashdot Mirror
Is the x86 Architecture Less Secure?
An anonymous reader asks: "Paul Murphy at CIO Today reports that a specific Windows buffer overflow vulnerability ' depends on the rigid stack-order execution and limited page protection inherent in the x86 architecture. If Windows ran on Risc, that vulnerability would still exist, but it would be a non-issue because the exploit opportunity would be more theoretical than practical.' And implies that other Windows vulnerabilities are actually facilitated by having an x86 chip." How does the x86 processor compare with other architectures when it comes to processor based vulnerabilities? How well have newer additions, like the Execute Disable Bit, helped in practical situations?
all x86 processors have an evil bit
Paul Murphy, I'd like you to meet Paul Graham. What we have here is an Apple press release being printed up as a trade journal article.
Good for Apple's PR firm. I guess.
Not that I have anything against Macs or PowerPC hardware, I just don't like disengenuous authors (or their articles).
Regards,
Ross
What, is there only one tech writer in the world? (See article two or three down on SCO)
If windows Ran on a RISC arch then it would be just as insecure . .If you know of a flaw in your architecutre then why are you programing
The fact is not that this issue is an insecurity in X86 but the fact that windows uses it
to that flaw .
The only things certain in war are Propaganda and Death. You can never be sure which is which though
2 articles in under 4 hours submitted by an "anonymous reader" that point to Paul Murphy at CIO Today. Hmmmm... Astroturf anybody?
"I'd rather be a lightning rod than a seismometer." -Ken Kesey
Blame the machine or blame the programmer? You can write x86 code without buffer overflows, period. That you can be more sloppy on other architectures and not get overflows seems silly. Like "everyone should drive Volvos cause they are safer."
Lots of things can be laid at the feet of x86 architecture, but not that it seduces programmers into writing code with buffer overflows.
"Eve of Destruction", it's not just for old hippies anymore...
And it's so secure that even I can't get admin privileges...
Badass Resumes
x86 has been around how long? 15+ years? And they just begin discussing this now?
Or, "Is Mac OS X on PPC less secure?" - It would be the same, worthless article if it were provided by Paul Thurott, on the opposite side of the fence.
This is just another guy that just got done giving Steve Jobs a blowjob. Let's move on.
If Windows ran on Risc, that vulnerability would still exist, but it would be a non-issue because the exploit opportunity would be more theoretical than practical.
Funny how exploits that are "just theoretical" don't stay that way forever...
Wer mit Ungeheuern kämpft, mag zusehn, dass er nicht dabei zum Ungeheuer wird. --Nietzsche
On x86, the stack grows backwards. Backwards! A stack overflow ought to overwrite unallocated space, not earlier stack frames and return addresses. It's totally insane.
But I guess when you live with insanity year after year, you get used it.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
But doesn't pretty much everyone use a compiler. And doesn't the compiler pretty much insulate you from such issues? What am I missing?
"Eve of Destruction", it's not just for old hippies anymore...
All in my opinion:
/\/\$ will go down without a fight? Nope, it'll be kicking and screaming one war at a time, IMO. This is the beginning of the "let's change everything to lock them all in" war which will be waged along side the war of patents. Just like the spoiled simpleton who declares "If I can't have it, no one will!" before going batshit crazy.
/\/\$ leap to the top again? Or will FOSS prevail? Remember Amiga? OS/2? Corel Linux? Etc? I'm sure one warlord will try and lock everyone into some new architecture because they will likely lose if they remain x86 only. I've seen this coming for several years and knew it was only a matter of time.
From recent news it smells like what will eventually happen is the internet and new architectures will all be redesigned to benefit one closed source OS. Do you think
So the wars will begin over BIOS, new and old architectures, patents, etc. The question is: Will
The real disadvantage of x86 over a RISC architecture like SPARC is that it doesn't have page protections (not to be confused with real mode segmentation which essentially disables the protected mode i386 MMU) where pages containing data and code are marked differently, so data pages are non-executable. sparcv9 implements a non-executable user stack per default, whereas it's a configurable option for sparcv8 binaries.
This has all changed with x86-64/AMD64/EM64T/x64/WHATEVER, which has brought a noexec bit to memory pages and allows hardware buffer overflow protection similar to SPARC. This still isn't a silver bullet for buffer overflows, but it's certainly better than nothing.
Still here? Dammit...
SIG: HUP
..so what if I have 0.999997 viruses in my CPU?
Thanks, Slashdot -- I actually read that boatload of ignorant gibberish, and now I'm measurably dumber than I was before I clicked the link. Keep this up and I too will be making specious arguments about "RISC" and "CISC".
To spur "enterprise Linux," Big Bang, the distributed two-phase commit.
Now really, we all know that x86 sucks noodle for various reasons (A20 anyone?), so why does it draw attention when somebody says it out loud? It wasn't so much designed, rather cobbled together with cludge upon cludge to retain backwards compatibility. It's all known!
Granted, if it kills x86 once and for all before yet another actually useable arch like Alpha is eradicated, it's not bad.
Fight hunger. Filet a politician and send him to a 3rd world country of your choice.
SO! We now know the truth: Microsoft is blameless for the shoddy security of their products. It's all the fault of the x86 architecture.
After all, how could Microsoft be expected to learn the intricacies of their primary platform and write code that does what it's supposed to?
We have been lied to.
Intolerance for ambiguity is the mark of the authoritarian personality.
For starters, Windows does run on RISC.
The stack behaviour of PowerPC is just as predictable as x86, and it's just as easy to perform a buffer overflow attack on vulnerable code.
PowerPC doesn't offer more per-page protection than x86, and it offers less than x86-64, as x86-64 can disable execution on a per-page basis.
It's possible to do things on both architechtures like add a random offset to the stack or load libraries at random locations. This makes attacks much more difficult, and OSes like OpenBSD do them on both architechtures. OSes like Linux or MacOS don't do them on any architechtures. Stack protections like propolice are a compile-time option and can be used on any OS on any architechture.
The mainstream architechtures of today do very little to distinguish themselves from each other security wise. One of the the few features that is different from one architechture to another, per-page execute protection, is not available on PowerPC.
This guy doesn't know what he's talking about.
I rarely criticize things I don't care about.
for starters, the x86 architecture can't be virtualized which is a real big setback.
The war with islam is a war on the beast
The war on terror is a war for peace
nt4 and some early versions of windows 2000 run on alpha ,mips i think that there was a sparc version to but that one did not last for long.
"Thanks, Slashdot -- I actually read that boatload of ignorant gibberish, and now I'm measurably dumber than I was before I clicked the link. Keep this up and I too will be making specious arguments about "RISC" and "CISC"."
Bet it got a low PageRanking(TM).
So according to this article, Linux, OS/2, BSD, Solaris for x86, etc. are all just as insecure as Windows on x86? What about when WindowsNT ran on MIPS or RISC or Alpha? Was that not insecure?
Linux, BSD, and other *nix systems are reasonably well protected through the design of the system and the widespread use of common server programs, which are checked and re-checked for these problems by a variety of people and organizations. Also, GCC provides ProPolice, which can help lock things down a bit more. I think this particular problem mostly applies to systems running Windows.
Microsoft's business problem in this regard is that they have no control over the applications running in Windows, and they provide a default Windows install that is quite open and vulnerable. Locking down the ports and getting rid of the most dain-bramaged policies in Windows is only one part of the solution. Vulnerabilities in application programs can still be used to break into these systems, and Microsoft will ultimately be blamed.
Perhaps the best thing Microsoft can do is integrate something like ProPolice into the C and C++ libraries used to compile programs for Windows. This would make a big difference in protecting the stack of running programs that are not designed with security as a priority.
If x86 really is less secure by nature, it probably wouldn't hurt if they'd put their virtualization engine (similar in function to VMware but not even half as good) right into the core OS. Under such a design, only the Windows kernel would run directly on the processor; the rest of the operating system and all of the application programs would run with the same x86 instruction set, but through the virtualization engine. There, checks could be made to prevent the most common vulnerabilities of the x86 processor from being utilized.
while the NX bit can help prevent the execution of malicious code on the stack after a buffer overflow, it doesn't solve the security problem posed by overflows. return-into-libc attacks can easily be executed and will become much more prevelant as NX-enabled PCs filter into the mainstream. address space randomization can help make rilc attacks harder on 64-bit architectures but is pretty useless on 32-bit archs.
Paul, let me explain how to be an industry analyst... 1) NEVER NEVER NEVER refer to anything that puts Microsoft in a bad light. After all, they pay the bills. 2) NEVER NEVER NEVER mention pinko-commie-bastard linux without mentioning how the TCO is lower on Windows, reliability is a myth, and security is virtually non-existent. 3) Lastly, land a gig working for a real tech think-tank, like the Yankee Group (TM). CIO Today? Who reads that rag anyway? You get more press from these slashdot lusers than you do from a bunch of clueless pointy-haired bosses. Love, Laura Groom of the Stool to Lord Bill
Soooo, how much money did that guy get paid to find MS another excuse not to fix their buggy OS?
Informative post, but it's "Administer".
But besides that, whether a buffer overflows or not is not a hardware issue, it's a program bug. If a programmer is so unclever as to allocate a buffer using a temp array on the stack and not bounds-check his code, well, unemployment should result.
Yeah, someone did piss in my Wheaties this morning.
Raise your children as if you were teaching them to raise your grandchildren, because you are.
Althought the insecurity of code that is only 'theoretically' exploitable ought to be fixed (we all prefer bug free code, right?) many theoretical exploits will never be practically exploited for technical reasons.
There is a distinction here which needs to be made between code which is exploitable but for which no public exploit code or method has been released -- in which cases it 'wont stay that way for ever' -- and code wherein the calculation of an arbitrary or runtime offset (e.g for a buffer overflow) is impossible and guesswork is impractically unlikely. Theoretical insecurities of the latter type are very likely to 'stay that way for ever'
use Blunt::Instrument;
"Yeah, someone did piss in my Wheaties this morning."
That was me. Sorry.
Did you happen to actually read the article? The guy ends by blatantly stating that there is no sane reason to choose a PC over a mac. How can you possibly see this guy as an MS supporter,.. unless of course you didn't really read the article.
Whare have we heard that before?
This will always be a problem until programmers read a good book on secure programming or take a secure programming class to learn how to write code without heap and buffer overflow vulnerabilities.
Think about it...if a virus could never read it's code out of memory, you would never suffer from it...worms would die, and all malware would stop working! It would be great!
Better yet, you can use the Signetics chips in both PCs *AND* Macs!
ttyl
Farrell
CAN-CON 2019 - Ottawa's only book oriented Science Fiction Convention! October 18-20, Sheraton Hotel, Ottawa, Canada h
I just read this article recently in Embedded Systems Programming magazine. http://www.embedded.com//showArticle.jhtml?article ID=55301875
After a detailed explanation of the hardware protection features built into the x86 (since the 80386), the author makes the following statement towards the end of the article:
"Too bad Microsoft doesn't use this feature. Windows has been plagued by buffer-overflow bugs that could easily be prevented by the processor's segmentation features. Alas, even though these features have been built into every x86 chip for more than 15 years, Microsoft has never used them. Instead, Windows creates a "flat" memory system with no segmentation, no tasking, no bounds checking, and no privilege protection, and then struggles to duplicate all those features in software. The result has been famously ineffective."
Driving a safe car provides you an extra chance of making it in a crash.
Writing poor code is more like not utilizing the workings of your vehicle (braking only with the parking brake?), hence driving it insecurely because of sloppiness.
However, all other non Harvard architectures will suffer the same fate, as they all have the same flaw. RISC isnt a magic trick to fix all evils.
Its simple: dont mix code and data.
---- Booth was a patriot ----
while my knee-jerk reaction was "well, paul has already demonstrated how trustworthy he is (see SCO article)", he actually has some valid points. mainly, pointing out that the average joe sixpack compares 6 year old iMacs running OS9 to modern PCs running WinXP and Linux.
My new blog
Check Raymond Chen http://blogs.msdn.com/oldnewthing/archive/2004/09/ 14/229387.aspx
If you are a bit curious why most C compilers don't do this as well. It is possible on x86 to use the stack pointer only for return addresses and then some other register to point to a "value stack" in some other disjoint area of memory. Not only would this make it easier on debuggers (crawling backwards from the current stack frame) but also lessen the impact of a typical return address remote code execution style buffer overflow.
However there is a down side to this, on x86 there are so few registers that to have two stack pointers is going to make code way more ineffeicient (many more spills to and from the stack). At least x86-64 doesn't have this problem, so there is one side of the "suckitude" of x86 right there (but hey, the string instructions are nifty data movers, I wish other CPU's had them at x86 speed).
So there are some architectural issues in x86 that are inherently bad when it comes to security. Then there are features that are inherently good but hard to use (segment registers, descriptor tables, and the "onion ring" enforced HW security).
The issue with stacks growing upwards (and heaps growing downwards) is pretty true. Having a stack growing downwards is a bit less secure because buffers tend to grow upwards in memory. Accessing past the end of an array is a much more common bug than accessing too low. Although its amazing how simple data validation failures can result in some interesting addresses being generated.
Disclaimer: I am a low-level snobb who writes code in assembly and C that has to have microsecond-accurate performance on old Motorola 68k's, so telling me to use java or some other interpreted high level language where the runtime footprint is larger than the amount of RAM I have to work with ain't gonna cut it. It may work for business apps but not embedded systems!
A longitme friend has a Sun 360 that's permanently on the net. a 25 Mhz MIPS processor isn't exactly as desireable target to skript kiddez, nor does it have the ability to saturate a network link...and you'd need 40 times as many to create your vast Zombie Horde.
Christ, creating a SSH key takes a good 30 seconds.
"Draco dormiens nunquam titillandus."
Using a segmented address space, where the Stack and Code are kept in what are effectively different address spaces, would do much to mitigate the effect of buffer overruns. On the other hand, the NX bit on x86-64 accomplishes basically the same thing, without the overhead of having to use long pointers to access data on the stack.
Neither of them are really all that robust though, since any time you can overwrite the return address on the stack, you can cause execution to veer off to somewhere else. Maybe you won't be able to insert shellcode into the program's address space, but if you can cause a function to "return" to something in the C standard library, like remove(), you can still cause havoc.
A more secure solution would split the stack such that function arguments and return addresses are not stored in the same space. This would give you a somewhat Forth-like runtime model, where return addresses are stored on one stack, and data values on the other. In that case, a buffer overrun in one function would still allow you to overwrite the arguments to another function, which is sub-optimal.
If you combine a split stack with growing the stack in the non-obvious direction, then you're probably as secure as you're going to get without eliminating the use of a stack altogether.
-Mark
Your signature is too long, it is being cut off mid-word.
Buffer overflows are just down to sloppy programming. They have nothing to do with architecture. Sloppy compilers add to the problem. Program are rarely scrutinised at machine code level, programmers are forced into a culture of producing quantity, not quality.....
The stack direction has nothing to do with security. You can still have stack protection running up or down stacks. Once you have a reasonable MMU, all further problems are due to software design.
Engineering is the art of compromise.
"The PowerPC stack grows downwards as well"
The PPC architecture doesn't have a stack pointer register, or any dedicated "push" or "pop" instructions. The stack growth direction is an OS feature, not a processor feature.
-Mark
there's something called good programming practices.
And Linux with PaX too.
I think a future version of X86 should have virus execution assistance in hardware.
Given that you just can't stop the things, why not offload the burden of running them from the processor?
BIPs (Bots Infected per Second) could be the metric for performance.
You're just not supposed to feel old at my age... somebody please come along and talk acoustic couplers... I know I've never used those. I have whislted to a modem before, though.
SIG: HUP
You could use a language like Java ,Python or Ada.
Or some good programming practices.
CAN-2004-1134 is a buffer overflow issue. The Mac is susceptible to buffer overflows.
Take e.g. the iSync issue. Apple doesn't go into details, but if you do a Google search on "isync vulnerability" you will find:
"The vulnerability is caused due to a boundary error in the handling of the "-v" and "-a" command line options. This can be exploited to cause a buffer overflow by supplying an overly long argument (over 4096 bytes). Successful exploitation allows execution of arbitrary code with the privileges of the mRouter application."
A proof of concept exploit can be found at. It opens a root shell.
When the PowerPC jumps to a subroutine, the return address is stored in the lr register. The first thing the prolog code in the subroutine does, is to put the address on the stack (freeing up the register for further function calls). So, a would-be hacker can overwrite the return address. For a description of how to take advantage of buffer overflows on the Mac, see "Smashing The Mac For Fun & Profit".
"Administrate isn't a word"
From the OED:
administrate v.
[f. L. administrat- ppl. stem of administra-re: see administer (cf. demonstrate, etc.).]
1. A by-form of administer v. (a sacrament, oath, medicine).
1651 Calderwood Hist. Kirk (1843) II. 38 That no maner of person, in time coming, administrat anie of the sacraments secreetlie.
1733 G. Cheyne Eng. Malady (1735) Pref., When Lithotomy cannot be administrated.
1855 Milman Lat. Chr. iii. v. (1864) II. 70 The delinquent clerk might be deprived for a time of his power of administrating sacred things.
2. To manage or direct (affairs). Now usu. absol. or intr. Cf. administer v. 1.
a1639 J. Spottiswood Hist. Ch. Scot. (1655) v. 241 A Lieutenant should be appointed..with full authority to administrate all affairs.
1848 Tait's Mag. June 397/2 The people is sovereign, its representatives administrate.
1934 G. B. Shaw On Rocks Pref. 150 What was formerly called 'real property' is replaced by ordinary personal property and common property administrated by the State.
1965 New Statesman 17 Sept. 400/3 Bishops, prime ministers, official people loved it... One is simply administrating in a fantasy world.
1981 Times 29 Apr. 9/6 The machinery of such aid is still primed by administrators eager to go out and administrate.
3. To organize or manage the recording and application of information in (a list, register, etc.).
1977 Wandsworth Boro' News 16 Sept. 19/4 (Advt.), Part-time..ledger clerk required to administrate sales ledger (mechanised).
1982 Times 12 Oct. 12/6 A claims register, administrated by an International Sea Bed Authority, would have been a simple answer.
If we actually did the bad thing and used selectors rather than the flat memory model, it would compromise performance, but it would be a lot more secure. You could, for example, put code for each module in an application in its own segment and then use only special segments to facilitate communication between application and libraries.
This is my sig.
Xix.
"Everything is adjustable, provided you have the right tools"
Nowday, what I see on the news are stories
about Michael Jackson, Mrs. Stuart, and the Pope.
This is what is passed as "news". Is the
media biased towards the left or towards the
right? When all they do is talk about
the unimportant, the media is not biased at
all! They are just silly.
- The telnetd AYT heap overflow (2002) could be exploited on x86/*BSD systems specifically because of their memory layout and little-endianess, while MIPS and SPARC systems were saved by their big-endian, 64bit addresses. Yet, on x86/Linux it was not exploitable, because of a different memory layout within the heap.
- The Solaris login heap overflow (2001) could be exploited on both x86 and SPARC. The reason were that addresses are created by the vulnerable code itself.
- The SSH1 CRC32 overflow (2000), has been exploited on every known architecture, x86, SPARC, MIPS, etc. because the data used to overwrite memory with were created by the vulnerable code itself, hence endianess and order did not matter.
Now, there are cases where RISC architecture makes exploitation more difficult to impossible. But there are around an equal amount of cases where x86 is saved. But the reason is not to be found within the architecture alone, but within differences in the whole chain from CPU to process memory layout to ABI and runtime environment. The following are especially important to determine if a vulnerability could be exploited on a given system:- CPU, word width and endianess
- process address layout
- stack frame handling and layout, how registers are saved (register windows?) order of registers/parameters/locals/alloca
- heap handling (i.e. what malloc allocation system is used. For example, most *BSD systems use an out-of-chunk management to control the heap structure itself, while glibc uses an inband management, which is by nature more likely to allow exploitation)
- compiler optimizations, eg. if small functions are inlined omitting stack frames, etc.
- ...
Speaking with more than eight years of exploit development experience, there is much more to consider than just the CPU type.it's a known issue that the intel x86 platform is vulnerable to stack-based buffer overflow exploits. the amd64 architecture is addressing this by providing hardware page protection which prevents code from being illegally executed off the stack. netbsd has enabled this feature by default in netbsd 2.0. i look at the x86 platform like training wheels and amd64 like a nice racing bike... ;-)
Mr. Jackson and Mrs. Stuart are not that important in the grand scheme of things, but the Pope is. That's because he's the head of the largest and most influential denomination of the largest and most influential religion in the world. I would have to check a current almanac, but I suspect he's a leader to more people than any other leader in the world.
Just because he doesn't have armies and navies, or platinum albums, or a line of towels at KMart, doesn't make him unimportant. He may not be important to you, but he's important to half a billion people or more. That's significant.
If he's only a tenth as influential as his predecessor was, his election is more than newsworthy.
Don't blame me, I didn't vote for either of them!
But it's tough to run C on that kind of architecture. C wants pointers to be addresses. The "array is a pointer" convention is a bad fit to a true segmented architecture. You can run Pascal just fine, but running C is tough. It can be done, but basically requires allocating all the variables in one big "array" at the hardware level, so you lose the protection. When C came in, the Burroughs machines (by then the Unisys A series) died off.
So it's quite possible to fix this, but you have to dump C. This may happen as Java and C# get more traction.
C++ doesn't help. It's part of the problem.
Unfortunately, it's far too late. :(
isn't that where virtualization can come in and help? Isn't this a nice way to guard against total catstrophe? If all it can do is hose one running application (or your stack of apps) and a barbeones kernel for that,you can poof it away easily (or store separately for analysis) once it becomes obvious to you or the machine this is occurring. Then when you respawn what you want, it's in a clean state, and you *don't do* what you did previously which you now know was a bad idea (i.e. : run this new to you sploit or chunk 0 bad code)
I'm not a coder but this is my laymans understanding of this technique. Or am I understanding this incorrectly?
the answer would be yes, no, or it used to be.
http://cvs.openbsd.org/papers/auug04/
Theo talks about how OpenBSD uses various available processor features to increase system attack resilience, w/minimal performance impact. The design choices made for architectures with differing degrees of per-page protection are presented. The concepts are not at all OpenBSD-specific, although the implementation discussed is, of course, OpenBSD.
And the solution is FORTRAN.
No seriously, flame all you want, but FORTRAN, even FORTRAN 77, is perfectly suited to development in a modern environment. I don't think you can prove otherwise.
You'll tend to see rewritten press releases in the business section. The front page of most newspapers originates in wire service articles: AP, Reuters, AFP, sometimes big national papers like the Washington Post or the New York Times.
If you click through a news story from a news aggregator like Google News, you'll note that many of them have identical text, because they're literally repeating the AP wire service story, crediting the original AP writer and all.
Actual reporters are used primarily for local news; very few newspapers have staff anywhere else. Most don't even have reporters in Washington, much less Paris/Jakarta/Darfur.
The bias comes not so much from the writers as from the editorial choices of which press releases and wire reports they're running and what page they put them on.
Either way, they rarely get the skeptical eye you'd really hope they get before receiving the imprimatur of being printed in the newspaper. Even a few phone calls would be nice.
It turns out, driving accidents are due to a problem inherent in all cars. And all cases of obesity and anorexia are due to a problem inherent in all food. Oh, and airplane crashes are due to a problem with the air.
Paul Murphy == Jeff Gannon ?
It looks like most operating systems like relying on C. Wouldn't C# or Java require a VM and hence a little shakedown on the OS architecture? And wait, what would the VM be implemented with? There seems to be a strong case that a good hardware architecture can only be of help. The bad one, irrespective of what runs on top of it might always provide a source for trouble. Application developers have always tried to rely on a nice language + compiler + framework as they are evolving.
No Greater Friend, No Greater Enemy! (Lucius Cornelius Sulla)
no viruses here though. Maybe I'm running the wrong x86 machine. I'll have a look on my windows x86 machine to see if it has any viruses..... .... ....
Opps, found some. I wonder what the difference is between my Linux/x86 and Windows/x86 ? Whys has my windows one got viruses ?
Anyone care to help me out here ?
if
The government does that over here.
and the Mac OS X 10.4.0 didn't cost me anything.
:-)
Actually the hardware was sweet and the OS it came with was OS X 10.3.9 and it had an upgrade DVD which I am also using to upgrade my TiBook and an old iMac (or two or three.)
Jobs gets his pound of flesh from the sale of hardware. If I really needed Linux (I use it on a server [and I also have a W2k box]) I would get it and think nothing about it. It didn't cost me anything.
Apple doesn't have a monopoly on anything, not even intelligent design.
I'm sure you can buy a 970FX from somebody else. Apple isn't the only system builder IBM sells to.
MSBPodcast.com The opinions expressed here are my own. If you don't like 'em... Think up your own stuff.
True, C# and Java would need a VM. However there are traditional (non VM) languages which have build in buffer protection. Fortran was mentioned by another poster - I would add Ada to the list.
Unlike common believe they are suitable for low level system programming. They are also not old and outdated - both Ada and Fortran have current (not older then 10 years) ISO standards and will get a new ISO standarts soon.
The only problem is that the names are not common buzz words.
Martin
The Catholic Church counts some 1.1 billion members, give or take, so about the size of China, or perhaps a little less. Islam is the second-largest religion with about 850 million adherents, though this does not include sects such as Sunni and Shi'ite, which the Catholic Church basically is.
You can never go home again... but I guess you can shop there.
There is also a "Media Watch" type program called "Fox News Watch" on, what else, Fox News. It airs Saturday at 6:30pm EST. It's the only appointment viewing I have all week. It's insightful and entertaining, and manages to do both at the same time. They have even (gasp) questioned Fox News motives on occasion.
The panel is two on the right and two on the left. The moderator attempts to stay in the center. I'm serious, it's a very well done show, and the moderator Eric Burns is a great host. It's probably the best show on Fox News.
It's mandatory to wash your hands before returning to the land of Dairy Queen.
You're TWENTY???
Heck, son, I have socks older than you. I have a COMPUTER older than you, still sitting in my closet. And I still have 5 1/4" floppy disks for it.
Wait, I'll go dust off my copy of Hellfire Warrior by Epyx. Best game ever written (think Diablo ||, but instead of a 3D landscape you had empty rooms with numbers, and you had to look up the number in a book, and that's where you got a description of where you were).
Feel better?
Nothing is inexplicable; only unexplained -Tom Baker, Doctor Who
I would have said that the most obvious hardware-specific feature, that would protect against stack overflows, is Harvard architecture (vs. Von Neumann, present in almostall CPUs today).
In Harvard architecture, data and program memory are separate and separately accessed. This has a speedup benefit, as you can access the data in the same cycle you access the program memory, but the other advantage is, a stack overflow will not corrupt your program. For an example, the Atmel AVR risc microcontroller family uses Harvard architecture.
Sigged!
Comment removed based on user account deletion
If you didn't include the only two sects of Islam then the count would be zero.... All muslims are one or the other.
Bad analogies are like waxing a monkey with a rainbow.
No they're not.
That's why people will end up thinking that Trusted Computing is a Good Thing(TM) -- the whole x86 Architecture is flawed, that's why we have viri and stuff.
why do you have to use a long pointer to access the stack when using a segmented memmory model? isnt that what a stack segment register (SS) is for? so in the 64k .tiny model both the code segment register and the stack segment register are equal and so stack addresses are "short" relative to the code, but just cause SS CS doesnt mean you need to use a long to access the stack.. or are you saying that because you need to use a segment override to do a mov ax,ss:[bx] (not sure if thats legal?) ?? but push ax will be the same in either case, wouldnt it?
No, the harvard architecture dates to much earlier then that.
---- Booth was a patriot ----
He's right, you know. Remove the x86 chip from your PC machine and it is very unlikely that the Windows installation in that machine will be compromised, except by someone with a physical access to the machine.
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
In another article on Slashdot today it's mentioned that Eric Raymond recommends Microsoft "open document formats" and "adhere to standards". Document formats aren't really an issue with Apple, but Apple is doing a very nice job of adhering to open standards these days. BSD Unix, Java, OpenGL, PDF, TCP/IP, X11...Apple is much more programmer friendly than it has ever been. The G5 machines are also very competitive on performance.
If you need access to commercial applications, or would rather spend money instead of time to accomplish your computing tasks, Mac makes a lot of sense compared with Linux. Windows, for me, is a distant third due to the time lost dealing with security issues, and a general distaste for programming something that inelegant. Besides, I can target Windows using Java with very little pain.
Just my $.02.
Galileo: "The Earth revolves around the Sun!"
Score: -1 100% Flamebait
I find it so distressing when things like this show up on Slashdot. "X bad thing is dependent on Y characteristic of Z, which A doesn't have, so therefore, I suggest that A is better." No overall comparison of the two, no accounting for potential vulnerabilities in "A" that might not exist in "Z", and no accounting for the fact that since "Z" is almost always far more prevalent in the world than "A", more effort has been expended looking for bad things.
You would be using the exact same logic if you said, "There's a vulnerability in a model of Hamilton bank vaults relating to the way the 5-inch bolts secure the door. The little safes that are sold in Staples and Office Depot don't use these kinds of bolts...so they're better safes, right?"
For your security, this post has been encrypted with ROT-13, twice.
I've noticed, in FC3 many binaries distributed have their executable stack flag cleared. Doesn't this mean it is invulnerable to stack under/overflow attacks, in AMD Duron and Athlons? See execstack(8)
Define "influential", please. If you mean "having influence on someone's behavior", then certainly Michael Jackson is, or rather used to be, pretty much an influential person. Of course, by that criteria the Pope, too, influences the behavior of hundreds of millions of people, so, yes he is important.
But important to the point of deserving nearly 100% of the world news media for more than two weeks? No, I don't think so. Who follows the Pope's recommendations anyhow?
Take sexual behavior, for instance. Exactly how many people in the world are so faithful catholics that they believe abstinence is the only acceptable solution for sex-related problems? Among the billion or so people who are labelled as "catholics", how many engage in sex before marriage, how many use condoms or contraceptive pills?
The pope is in the spotlight, and all the people who feel an emotional linkage to him certainly make him important, just like Michael Jackson or the queen of England are important in that sense. But I do believe there's something like overdoing it.
I always wondered why the stack didn't grow outwards into unallocated space?
What advantage does it give the chip to have the stack grow backwards?
It seems dangerous and lacking in good design.
Ok, lets test this theory out: compare an NT x86 system to an NT Alpha system with the same patches. Can you exploit the same vulniablities?
How about comparing Debian running on a RISC archtechuare to x86 running the same build?
You say things that offend me and I can deal with it. Can you?
Oh, yeah? Try getting data from an Oracle database in FORTRAN. They used to have something called, IIRC, pro*fortran, but no more. It took me about six months of interaction with people deeper and deeper in the Oracle organization to find out that that product is "deprecated" and no longer supported. Have you ever tried porting a FORTRAN program from VAX/VMS to whatever modern environment you use? Or from a PDP-11? So here is one reason why FORTRAN is dead: important software companies no longer support it.
Another reason: try finding programmers who are experienced in it. Where I work they have a 20-year-old system entirely written in FORTRAN. In the last twelve months, three junior engineers have quit their jobs because an old dinosaur insists that they must keep doing everything in FORTRAN instead of calling the old functions from C programs. What's the point of having "FORTRAN" in your resume, if the job market for that skill is so restricted?
But these are practical reasons, you wanted technical reasons, I guess. So try this: how do you do string manipulations? Functions that are one-liners in C become two pages long in FORTRAN. Or how about dynamic memory allocation?
I have used FORTRAN a lot in the past. I have seen its long and slow agony. I have seen the countless different standards, the many people and organizations who have said, "sure, you can do that in FORTRAN, do it like this" and have come with a solution that's incompatible with everything else.
Maybe FORTRAN could have evolved differently, if it wasn't so much a "commercial" software. All companies did incompatible improvements to FORTRAN so their marketing people could say "ours is the best FORTRAN in the market". Endless forking while C evolved in a standardized way. Today, to link a VAX FORTRAN library with an Oracle-accessing FORTRAN program originally written in AIX, for instance, is so hard that the easiest solution is to rewrite everything in C.
But I know people like you who believe FORTRAN is still the solution. As I mentioned, they are running through junior engineers at a fast rate. Luckily, that's not my department, here we do everything in either C/C++ or PHP.
Random offsets won't help much -- they'll help some, but what if you can write a LOT of data into that buffer? Give it a LARGE NOP sled.
Detect when a process is doing a lot of NOPs in a row and kill it? Ok. Use "AIAIAIAIAIAIAIAI..." 'A' = 0x41 = inc %ecx, 'I' = 0x49 = dec %ecx. Together, they are an effective NOP. Hell, most of the time, "AAAAAAAAA..." is an effective NOP. Does an attacker really care what's in ECX?
The problem is NOT the architecture, NOT the OS, and NOT the language. It's not a problem with libc, stdio, strcpy, or anything else. If you haven't figured this out by now, you might want to read about computer architecture -- computers do what you tell them to. I can write secure code in which I strcpy() from untrusted data into a static buffer on the stack, on an x86 running Windows with no NX. Hell, I'll even do it in real mode.
I'm not a DJB fanboy, but he does have quite a few good points. Programmers are lazy. Write secure code.
I mod down pyramid schemes in sigs.
It's the same guy that thinks SCO have a good case as reported here some days ago:l ?tid=123&tid=136&tid=88&tid=155
1 84804444
http://yro.slashdot.org/yro/05/04/29/1950245.shtm
And since also on Groklaw:
http://www.groklaw.net/article.php?story=20050429
The vast majority are. And there are NOT more than twice as many Muslims as Catholics in the world.
The Vatican has troops.
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
Sunni and Shi'ite sects make up the significant majority of Muslims, but there are other sects. I know of the Druze, Alawi, and Ismali (Ismaeli?), but there are others, though even combined they are a very small percentage of the overall religion.
You can never go home again... but I guess you can shop there.
I fondly remember programming in C/C++ on x86 machines running OS/2, where attempting to write beyond the end of an allocated block of memory (incl. stack) caused an immediate interrupt. Great for debugging, and also much more secure against buffer overrun attacks. Why? Because in OS/2 each allocated block of memory was its own segment, with its own protection levels. Windows, unfortunately, just allocates one big segment from x86 hardware, so hardware-based memory protection is effectively disabled.
But important to the point of deserving nearly 100% of the world news media for more than two weeks?
A gross exaggeration. Try to stay in the same reality as the rest of us.
Don't blame me, I didn't vote for either of them!
From where I'm sitting, it would appear to me that Sufis account for quite a large proportion of Muslims. It's simply that they don't happen to greatly signify in the political hotspots where the US administration has taken pains to demonise Muslims.
I'm not sure why you mention numbers of Catholics, since I never did.
Well true, nothing of corse. Prehaps a bit complex since VM instructions are ver high level.
As for "sandboxing and privilege separation: if you think of the four privilege rings in the x386 architecture then it has allready been done. Only that most OS don't actualy use that feature of the x386 architecture. (i.E. only use ring 0 and 3).
Other posters pointed that out allready: the available savety feratures of the x386 arn't actualy used.
Martin
If you look around Paul Murphy's website, I think it starts to become clear that this guy has some sort of grudge against microcomputers. He's enamored of Unix on the mainframe, and believes that any other platform/operating system is a mere plaything.
He probably has a shrine devoted to Scott McNealy in his basement.
There's no point in employing sound reasoning in an attempt to sway the opinion of a person like Paul Murphy. He's pathologically entrenched in his long-held beliefs. Pay no attention to his addlepated bullshit.
...and whichever it is doesn't matter.