|
> Is the iseries invulnerable to buffer overflows? Not exactly, but what you can exploit with a buffer overflow is different than it would be for Windows or Unix. First of all, it's important to realize that memory on a computer is not only used for a program's variables or other data -- it's also used for executable code. A program is loaded into memory before running it, and the instructions that make up that program are executed from that memory. That means that if you can get a pointer to the code of a program, you can potentially change what it does -- making it do something else, such as send you a file, give you a command prompt, send out mass e-mails, or if the program is running with enough authority, upgrade your security priveledges. Now, my knowledge of how Windows works is dated. I know that back in the old days, once you managed to find a way to write data outside of the current buffer, you could pretty much access everything. All programs running on the same computer shared the same RAM, so you could change what other programs did as well as the current one. If there is a program running as administrator, changing that one -- or changing Windows itself -- allows you to do all sorts of nifty things. So, a buffer overflow in that scenario is particularly heinous. In Unix-like systems like FreeBSD or Linux, each process has it's own memory. Not exactly true -- I mean, it's the same RAM bank and all -- but the system creates a logical addressing situation where a pointer to memory is mapped from that process' memory to the actual physical memory. That way, a program couldn't access another program's memory, it is locked into it's own little world. (Unless, of course, you could find a buffer overflow in the kernel itself.) However, a buffer overflow can still do lots of damage. You can still insert code that can be executed in the current process, and if the current process every upgrades it's authority (kinda like adopting authority on the iSeries, but it can be done in the middle of a program) then you can do fun things like changing people's authority level, etc. The iSeries has two memory models -- one is a "mapped" model like Unix (called "teraspace") and in the other model called "single-level store" is able to access any memory on the system, plus it's able to access disk. At first glance, this seems like it would be even worse than Windows -- but it's not because of the way pointers work on the iSeries. A pointer on the iSeries isn't just an integer, as it is on those other systems. It has permissions embedded into it, as well as special "tag bits." The tag bits are designed to make it impossible for you to "manufacture" your own pointers so that you can only get them from the system's routines. (Though, there are ways to disable those checks by using SST's "display/alter/dump" utility to edit the machine code of your program.) Since you must go through IBM's routines to create a pointer, it has the ability to do some security checking. For example, it doesn't allow you to make a pointer to executable code unless your program runs in the system domain. There are also different TYPES of pointers on the iSeries. A system pointer points to programs or other executable code, and a space pointer points to data in variables and things like that. Since you can't artificially create a system pointer, a buffer overflow will always be using a space pointer. This makes it just about impossible to modify the code of a program in memory using a buffer overflow. Anyway -- getting back to the original question "is the iSeries invulnerable to buffer overflows?". No. You can overflow a buffer, causing other variables in the job to be wrong. This might be used to cause a web server to crash, or something like that. But, you can't change a running program, which really limits what you can do. And you run the risk of hitting memory that you don't have permission to, which will cause the program to crash. About the best you can do is a denial of service attack. The design of the iSeries is really an incredible thing. It's just one of the best designed systems out there! Unfortunately, very few people understand and appreciate this...
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.