Re: Probably the first published shell code example for Linux/390
On Monday 04 November 2002 09:02 pm, John Summerfield wrote: I know I'm being picky, but the 8080 wasn't that fast. Around 800 Khz I think. I refer to the 8080A, which I know hit 2MHz because I have such a chip here in my basement, waiting for the day when I turn it into a hand-wired S100 system (still have the other parts!) just because, well, because I can. The 8080 (non A version) is before my time, so I can't report on its clock speed. Scott -- - Scott D. Courtney, Senior Engineer Sine Nomine Associates [EMAIL PROTECTED] http://www.sinenomine.net/
Re: Probably the first published shell code example for Linux/390
On Monday 04 November 2002 09:02 pm, John Summerfield wrote: Then came our modern age, the age of flat memory models. Segment registers are anachronistic. Toss them out. One simple, flat memory model is the only way to go. The segment registers still exist. Their use was expanded and they got renamed. Their size was expanded, but they are not typically used to truly segment memory any more, as most systems use the unified, flat memory model. Also, the segments no longer point directly to physical addresses but rather to virtual addresses. The 80286 made things more complex than the 8086/80186, but the 80386 got *really* interesting. I haven't gotten my hands on the Itanium (what a dorky name!) architecture manual yet, but I'm curious to see what Intel came up with when they started with a clean slate. I have heard that the pipelining is extremely sophisticated and is capable by design of extraordinary efficiency, but also that it is very difficult to create a compiler that will generate instructions in optimal order for this complex multi-stage, multi-state, multi-path pipeline. Scott -- - Scott D. Courtney, Senior Engineer Sine Nomine Associates [EMAIL PROTECTED] http://www.sinenomine.net/
Re: Probably the first published shell code example for Linux/390
On Tue, 2002-11-05 at 14:11, Scott Courtney wrote: I haven't gotten my hands on the Itanium (what a dorky name!) architecture manual yet, but I'm curious to see what Intel came up with when they started with a clean slate. The core design is from HP and it shows - Itanic is much more like a super-parisc machine than an x86, although it does support hardware x86 back compatibility.
Re: Probably the first published shell code example for Linux/390
On Mon, 2002-11-04 at 15:32, Scott Courtney wrote: growing memory structure in the entire system. Really. Ask anyone who did embedded systems work back then. You avoided dynamic memory structures if you could because the programming and debugging tools were primitive and because often the applications were simple enough not to need them. And because dynamic memory structures needed to be managed by the application or at least the compiler runtime, and that took CPU cycles. With a clock speed of around 2 megahertz, and cycle times measured in microseconds, this mattered a lot. Or any games programmer for 8bit micros. When I then moved to a real computer (Honeywell L66) and learned B the malloc/free thing was actually quite a revalation. So they came up with the downward-growing stack. Put the stack pointer initially at one address above the top of memory, because PUSH and POP used predecrement/postincrement logic. If you were lucky enough to have a full load of 64K of memory, you could set the SP to 0x so that its first byte stored would wrap around to 0x, the top of RAM. In any case, init the SP at power up, don't use the top few words of RAM, and basically forget about the stack. They had lots of prior art to draw from, Subroutines go back to at least 1947, and subroutine call/return stacks to about 1952. By mid 1960 the burroughs machines had a fairly conventional stack.
Re: Probably the first published shell code example for Linux/390
On Mon, 4 Nov 2002 23:32, Scott Courtney wrote: because often the applications were simple enough not to need them. And because dynamic memory structures needed to be managed by the application or at least the compiler runtime, and that took CPU cycles. With a clock speed of around 2 megahertz, and cycle times measured in microseconds, this mattered a lot. I know I'm being picky, but the 8080 wasn't that fast. Around 800 Khz I think. Incidentally, I noted in one other post a comment that there should be hardware protection to keep from executing instructions off the stack. Great idea. Starting with the 8086, Intel *had* this hardware protection, because the stack had its own memory segment that could be physically isolated from other segments. You had to explicitly set the code segment register to point into the stack segment if you wanted to execute stack data as code. The 8086 didn't have any security features to keep malicious code from doing this, but at least it didn't happen by accident. Starting with the 80286, there were actually security privilege levels that kept application programs from tinkering with segment registers -- as long as you were running in an operating system that supported this. DOS, of course, didn't. Then came our modern age, the age of flat memory models. Segment registers are anachronistic. Toss them out. One simple, flat memory model is the only way to go. The segment registers still exist. Their use was expanded and they got renamed. On the 8086 family, segments were 64K. One the 80286 you can limit the size of segments through the use of segment descriptors, and the registers accessing them are segment selectors. With the advent of the 80386 with 32-bit offsets, software authors said That's heaps, well use single 4 Gbyte address spaces, one for code, data and stack combined. A reason was performance. I'd have thought most of the performance benefits would be achieved with a 32-bit address space for each, and you'd have much less trouble with array overruns and such. Hello simple memory management and portability. Bye-bye hardware stack protection. To be fair, I should mention that I generally *agree* with the flat memory model. It really goes a long way toward improving portability, since there are tons of hardware architectures that have no analogue to the Intel segment registers. But in dumping the segment registers, we didn't get our lunch totally for free. GRIN Some of those architectures came later, and if software authors had _used_ the Intel protection abilities, those architectures may well have been different. -- Cheers John Summerfield Microsoft's most solid OS: http://www.geocities.com/rcwoolley/ Join the Linux Support by Small Businesses list at http://mail.computerdatasafe.com.au/mailman/listinfo/lssb
Re: Probably the first published shell code example for Linux/390
Hello from Gregg C Levine Right John. The I8080 in its original form ran at 800Khz, then when it finally ran out, so to speak, they were up to about 4Mhz, but only in small lots. The rest of what you are writing about, you are quite correct. --- Gregg C Levine [EMAIL PROTECTED] The Force will be with you...Always. Obi-Wan Kenobi Use the Force, Luke. Obi-Wan Kenobi (This company dedicates this E-Mail to General Obi-Wan Kenobi ) (This company dedicates this E-Mail to Master Yoda ) -Original Message- From: Linux on 390 Port [mailto:LINUX-390;VM.MARIST.EDU] On Behalf Of John Summerfield Sent: Monday, November 04, 2002 9:03 PM To: [EMAIL PROTECTED] Subject: Re: [LINUX-390] Probably the first published shell code example for Linux/390 On Mon, 4 Nov 2002 23:32, Scott Courtney wrote: because often the applications were simple enough not to need them. And because dynamic memory structures needed to be managed by the application or at least the compiler runtime, and that took CPU cycles. With a clock speed of around 2 megahertz, and cycle times measured in microseconds, this mattered a lot. I know I'm being picky, but the 8080 wasn't that fast. Around 800 Khz I think. Incidentally, I noted in one other post a comment that there should be hardware protection to keep from executing instructions off the stack. Great idea. Starting with the 8086, Intel *had* this hardware protection, because the stack had its own memory segment that could be physically isolated from other segments. You had to explicitly set the code segment register to point into the stack segment if you wanted to execute stack data as code. The 8086 didn't have any security features to keep malicious code from doing this, but at least it didn't happen by accident. Starting with the 80286, there were actually security privilege levels that kept application programs from tinkering with segment registers -- as long as you were running in an operating system that supported this. DOS, of course, didn't. Then came our modern age, the age of flat memory models. Segment registers are anachronistic. Toss them out. One simple, flat memory model is the only way to go. The segment registers still exist. Their use was expanded and they got renamed. On the 8086 family, segments were 64K. One the 80286 you can limit the size of segments through the use of segment descriptors, and the registers accessing them are segment selectors. With the advent of the 80386 with 32-bit offsets, software authors said That's heaps, well use single 4 Gbyte address spaces, one for code, data and stack combined. A reason was performance. I'd have thought most of the performance benefits would be achieved with a 32-bit address space for each, and you'd have much less trouble with array overruns and such. Hello simple memory management and portability. Bye-bye hardware stack protection. To be fair, I should mention that I generally *agree* with the flat memory model. It really goes a long way toward improving portability, since there are tons of hardware architectures that have no analogue to the Intel segment registers. But in dumping the segment registers, we didn't get our lunch totally for free. GRIN Some of those architectures came later, and if software authors had _used_ the Intel protection abilities, those architectures may well have been different. -- Cheers John Summerfield Microsoft's most solid OS: http://www.geocities.com/rcwoolley/ Join the Linux Support by Small Businesses list at http://mail.computerdatasafe.com.au/mailman/listinfo/lssb
[hansolofalcon@worldnet.att.net: Re: Probably the first published shell code example for Linux/390]
Forwarded message from Gregg C Levine [EMAIL PROTECTED]: Right John. The I8080 in its original form ran at 800Khz, then when it finally ran out, so to speak, they were up to about 4Mhz, but only in small lots. The rest of what you are writing about, you are quite correct. IIRC the 8080 usually clocked at 2MHz for most of it's life; The 800K number may be more of KOPS rather than clock rate (though even that seems high based on my recollection). The 8080 was a *dynamic* chip so you couldn't single-step it by stopping the clock. The Z-80 used static logic so it could be dealt with that way- and the Z-80s were able to be clocked up to 4MHz almost right away. (The Z-80 is not completely dead, BTW; The Z-800 chip still exists, IIRC, and uses some cool tricks to handle more RAM.) The 8085 actually jumped past 4MHz (again, from memory, I once had an S-100 system w/ the CompuPro 85/88 CPU card) but I don't remember the final rate. There was some odd stuff to the 8085 that made it's instruction set incompatible w/ the Z-80. I don't know if any folks here remember that DRI had a PL/I for CP/M-80- Though I tended to use BDS C and then Aztec C. I even wrote a tool that'd make a tar floppy so we could pass files to a Xenix system. -- John R. Campbell Speaker to Machines [EMAIL PROTECTED] - As a SysAdmin, yes, I CAN read your e-mail, but I DON'T get that bored! It is impossible for ANY man to learn about impotence the hard way. - me ZIF is not a desirable trait when selecting a spouse. - me
Re: [hansolofalcon@worldnet.att.net: Re: Probably the first published shell code example for Linux/390]
On Mon, Nov 04, 2002 at 09:52:13PM -0500, John R . Campbell wrote: I don't know if any folks here remember that DRI had a PL/I for CP/M-80- Though I tended to use BDS C and then Aztec C. Remember? I may still have a copy. BDS C has recently been released into the public domain, both source and object. Google though comp.os.cpm for the details.
Re: [hansolofalcon@worldnet.att.net: Re: Probably the first published shell code example for Linux/390]
Hello from Gregg C Levine That near as maybe, John Campbell, but I was agreeing with John Summerfield, so I'm inclined to place my positions in the middle as I do not remember most of the things about I8080 as I should. About the Z80? A few. Now as to your assertions regarding DRI, and its software, yes, I think I did. I never really had a chance to get into CP/M much. --- Gregg C Levine [EMAIL PROTECTED] The Force will be with you...Always. Obi-Wan Kenobi Use the Force, Luke. Obi-Wan Kenobi (This company dedicates this E-Mail to General Obi-Wan Kenobi ) (This company dedicates this E-Mail to Master Yoda ) -Original Message- From: Linux on 390 Port [mailto:LINUX-390;VM.MARIST.EDU] On Behalf Of John R . Campbell Sent: Monday, November 04, 2002 9:52 PM To: [EMAIL PROTECTED] Subject: [LINUX-390] [[EMAIL PROTECTED]: Re: Probably the first published shell code example for Linux/390] Forwarded message from Gregg C Levine [EMAIL PROTECTED]: Right John. The I8080 in its original form ran at 800Khz, then when it finally ran out, so to speak, they were up to about 4Mhz, but only in small lots. The rest of what you are writing about, you are quite correct. IIRC the 8080 usually clocked at 2MHz for most of it's life; The 800K number may be more of KOPS rather than clock rate (though even that seems high based on my recollection). The 8080 was a *dynamic* chip so you couldn't single-step it by stopping the clock. The Z-80 used static logic so it could be dealt with that way- and the Z-80s were able to be clocked up to 4MHz almost right away. (The Z-80 is not completely dead, BTW; The Z-800 chip still exists, IIRC, and uses some cool tricks to handle more RAM.) The 8085 actually jumped past 4MHz (again, from memory, I once had an S-100 system w/ the CompuPro 85/88 CPU card) but I don't remember the final rate. There was some odd stuff to the 8085 that made it's instruction set incompatible w/ the Z-80. I don't know if any folks here remember that DRI had a PL/I for CP/M-80- Though I tended to use BDS C and then Aztec C. I even wrote a tool that'd make a tar floppy so we could pass files to a Xenix system. -- John R. Campbell Speaker to Machines [EMAIL PROTECTED] - As a SysAdmin, yes, I CAN read your e-mail, but I DON'T get that bored! It is impossible for ANY man to learn about impotence the hard way. - me ZIF is not a desirable trait when selecting a spouse. - me
Re: Probably the first published shell code example for Linux/390
True, but it is common virus technique to execute machine code by utilizing buffer overflows in a scripting language, and as such bypassing the limitations that are imposed by the scripting language. Jan Jaeger From: John Summerfield [EMAIL PROTECTED] Reply-To: Linux on 390 Port [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Probably the first published shell code example for Linux/390 Date: Sat, 2 Nov 2002 15:25:52 +0800 On Fri, 1 Nov 2002 22:50, you wrote: When we are talking about storing (ie overlaying) programs (trojans) on the Maybe I'm being picky, but trojans are always present by invitation. A user us sucked into installing a program that (maybe) does what's claimed of it, but also does something you might not like. -- Cheers John Summerfield Microsoft's most solid OS: http://www.geocities.com/rcwoolley/ Join the Linux Support by Small Businesses list at http://mail.computerdatasafe.com.au/mailman/listinfo/lssb _ Surf voor nieuws, filenieuws entertainment naar MSN.nl http://www.msn.nl/default.asp
Re: Probably the first published shell code example for Linux/390
On Fri, 1 Nov 2002 22:50, you wrote: When we are talking about storing (ie overlaying) programs (trojans) on the Maybe I'm being picky, but trojans are always present by invitation. A user us sucked into installing a program that (maybe) does what's claimed of it, but also does something you might not like. -- Cheers John Summerfield Microsoft's most solid OS: http://www.geocities.com/rcwoolley/ Join the Linux Support by Small Businesses list at http://mail.computerdatasafe.com.au/mailman/listinfo/lssb
Re: Probably the first published shell code example for Linux/390
When we are talking about storing (ie overlaying) programs (trojans) on the stack space, then only hardware protection can really help. One would need to come to a model where instructions cannot be executed from the stack. One can achive this in S/390, by making the stack space a separate space, which is only addressable thru an access register (like an MVS data space). This way instructions can never be executed from the stack space, however, I am afraid that such an implementation would break a few things. Jan Jaeger. From: Ross Patterson [EMAIL PROTECTED] Reply-To: Linux on 390 Port [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Probably the first published shell code example for Linux/390 Date: Thu, 31 Oct 2002 18:33:57 -0500 At 13:10 10/31/2002 -0600, Ward, Garry wrote: push something to the stack, decrement the address, and if you've gone negative, you've gone too far? Sure, and the same is true of upwards-growing stacks (only in the other direction, natch). The issue isn't accidental stack overflow. The difference is in the impact of storage overlays - if your stack grows down, the memory above the current stack frame is your caller's. If your stack grows up, the memory above it is your callee's. Now imagine storing 1000 bytes into a 10-byte buffer on the stack (the classic shellcode-insertion hack). In the grows-down case, you overlay some active memory including possibly the savearea containing the register's you're going to reload when you hit the return statement. In the grows-up case, you overlay some inactive memory. sorry, PC assembler is a long time past, but I vaguely remember the argument being made that top down stacking was easier to manage. That's true on platforms that actually have stacks (sometimes). The 8080 and it's descendants do, and Intel chose to grow them downwards. It's a design issue, just like little-endian-ness, and IMHO just as wrong. :-) S/390 doesn't have a general-purpose hardware stack, so it's a matter of implementation preference. Ross Patterson _ Je kan ook Messenger berichten op je mobiele telefoon ontvangen! http://www.msn.nl/services/hotmailsmsv271551/messenger/
Re: Probably the first published shell code example for Linux/390
Jan Jaeger writes: When we are talking about storing (ie overlaying) programs (trojans) on the stack space, then only hardware protection can really help. One would need to come to a model where instructions cannot be executed from the stack. One can achive this in S/390, by making the stack space a separate space, which is only addressable thru an access register (like an MVS data space). This way instructions can never be executed from the stack space, however, I am afraid that such an implementation would break a few things. Solar Designer did a non-executable stack patch for Linux/ia32 (using segment protection for the stack space since ia32 page-level protection does not distinguish read from execute). The things that a non-executable stack break are mainly (1) gcc trampolines (used for nested functions), (2) signal delivery and (3) application-specific run-time code generation. He handled (1) and (2) by detecting such code and disabling the non-exec stack on the fly (yes, this is a slight exposure). For (3), he supported a an ELF executable marker which disabled non-exec stack for the whole program. It was fairly popular and worked well against the sort of attacks which it was designed to prevent. Needless to say, people then worked out how to do some exploits even with non-exec stack (return into libc et al). The arms war continues, as always. --Malcolm -- Malcolm Beattie [EMAIL PROTECTED] Linux Technical Consultant IBM EMEA Enterprise Server Group... ...from home, speaking only for myself
Re: Probably the first published shell code example for Linux/390
Alan Altmark wrote: It's yet another reason to get a Linux support contract. ... or a distribution that offers free security updates for everybody! (SCNR) Regards, Stefan Gybas
Re: Probably the first published shell code example for Linux/390
This reminds me of that famous Pogo-ism: We have met the enemy and they are us. Ross Patterson Ross.Patterson To: [EMAIL PROTECTED] @Cox.Net cc: Sent by: LinuxSubject: Re: Probably the first published shell code example for Linux/390 on 390 Port [EMAIL PROTECTED] ARIST.EDU 10/30/02 07:35 PM Please respond to Linux on 390 Port At 11:08 10/30/2002 -0500, Post, Mark K wrote: And the key point here is that getting in simply requires modifying known exploits against vulnerable software with an S/390-specific payload. But it didn't have to be this way. If Linas Vepstas et al. had been able to finish the Bigfoot i370 port or if his attempts to influence the IBM s390 port had been successful, we wouldn't have this problem. Linas' port of GCC for Bigfoot had the stack growing *upward*, not *downward* as on almost every other platform. Almost half of the CERT vulnerabilities since 1 Jan 2000 are due to buffer overruns (even more if you assume multiple vulnerabilities includes some). And most of these buffer overruns are actually stack overruns, allowing the creative cracker to change things like where the current subroutine will return to (in particular, to code that does evil things like the phrack shellcode example). It's kind of hard to overwrite your caller's stack frame when it's at a lower address than yours. Linas explained it nicely almost two years ago right here: http://www.marist.edu:8000/htbin/wlvtype?LINUX-VM.1315. Ross Patterson
Re: Probably the first published shell code example for Linux/390
Simplicity? push something to the stack, decrement the address, and if you've gone negative, you've gone too far? PUSH DEC BN stack overrun BZ stack overrun sorry, PC assembler is a long time past, but I vaguely remember the argument being made that top down stacking was easier to manage. Garry E. Ward Senior Software Specialist Maritz Research Automotive Research Group 419-725-4123 -Original Message- From: Greg Smith [mailto:rys;epaibm.rtpnc.epa.gov] Sent: Thursday, October 31, 2002 1:33 PM To: [EMAIL PROTECTED] Subject: Re: Probably the first published shell code example for Linux/390 Ross Patterson wrote: At 11:08 10/30/2002 -0500, Post, Mark K wrote: And the key point here is that getting in simply requires modifying known exploits against vulnerable software with an S/390-specific payload. But it didn't have to be this way. If Linas Vepstas et al. had been able to finish the Bigfoot i370 port or if his attempts to influence the IBM s390 port had been successful, we wouldn't have this problem. Linas' port of GCC for Bigfoot had the stack growing *upward*, not *downward* as on almost every other platform. I've always been curious. Why is a top down stack used anyways ?? Of course I've been using a bottom up stack for almost 30 yrs so I might be biased ;-) Greg font size=1Confidentiality Warning: This e-mail contains information intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, any dissemination, publication or copying of this e-mail is strictly prohibited. The sender does not accept any responsibility for any loss, disruption or damage to your data or computer system that may occur while using data contained in, or transmitted with, this e-mail. If you have received this e-mail in error, please immediately notify us by return e-mail. Thank you.
Re: Probably the first published shell code example for Linux/390
Ross Patterson wrote: At 11:08 10/30/2002 -0500, Post, Mark K wrote: And the key point here is that getting in simply requires modifying known exploits against vulnerable software with an S/390-specific payload. But it didn't have to be this way. If Linas Vepstas et al. had been able to finish the Bigfoot i370 port or if his attempts to influence the IBM s390 port had been successful, we wouldn't have this problem. Linas' port of GCC for Bigfoot had the stack growing *upward*, not *downward* as on almost every other platform. I've always been curious. Why is a top down stack used anyways ?? Of course I've been using a bottom up stack for almost 30 yrs so I might be biased ;-) Greg
Re: Probably the first published shell code example for Linux/390
Ward, Garry wrote: Simplicity? push something to the stack, decrement the address, and if you've gone negative, you've gone too far? PUSH DEC BN stack overrun BZ stack overrun I've always been curious. Why is a top down stack used anyways ?? I understand that much but why did Intel want you to use a top-down stack ?? I remember from my Pascal days that you could reference your caller's local variables, so I guess it's easier to reference them in a top-down stack. Just a guess, I have no idea. Greg
Re: Probably the first published shell code example for Linux/390
James Tison wrote: The gcc package can be configured to have the stack grow either way, and if my light perusals of the kernel code (and my memory) are right, so can Linux. I would have to think that the final decision would have to do with memory mapping, guard pages, and vmm controls, as well as the stack frame format register mapping, of course -- more or less a matter of choice on ESAME hardware. I don't know why a downstack was chosen. Fortunately, there are people who chime in on this list all the time who have the definite answers. If they'd care to share them, I'm kind of curious too. :-) I don't think there are really strong arguments for either direction of stack growth on s390. I don't really buy either the efficiency or the security argument: efficiency comes with a well-designed calling convention, and I think you can find those for either direction; as to security, while an upwards-growing stack might make some attacks more difficult, you can find other types of attacks. In the end, as long as you face security exposures due to bugs in applications, the only sure way to deal with them is to fix those bugs; everything else is a temporary band-aid of questionable value IMHO. (And if you really want such band-aids, there are also some available for the downwards-growing stack, like kernel patches to make the stack non-executable or compiler patches to protect the return address with 'canaries' or the like ...) That said, as long as there is no overriding reason, there is always the general principle: Don't Be Different. We've always tried to make the s390 variant of Linux as similiar as possible to the other Linux variants in wide-spread use, foremost of course the Intel version. While in theory applications should not depend on platform implementation issues like the direction of stack growth, in practice there are always some that break. (I think HPPA did go the upwards-growing stack way after all, and there have been quite a few problems surfacing ...) As one of main advantages of Linux on s390 is the easy portability of so many applications from Linux on other platforms, it's really important to try not to make that porting unnecessarily harder. Therefore e.g. the application address space layout (including the position and direction of the stack) on Linux for s390 is nearly identical to the one on Linux/Intel, except that we have only 2 GB instead of 3 GB (and even *that* difference actually caused applications to break). Bye, Ulrich -- Dr. Ulrich Weigand [EMAIL PROTECTED]
Re: Probably the first published shell code example for Linux/390
At 22:52 10/31/2002 +0100, Ulrich Weigand wrote: while an upwards-growing stack might make some attacks more difficult, you can find other types of attacks. Absolutely true. And so I'd agree with you that stack direction didn't matter, except that the Standard C library includes some functions that are so open to this particular problem that it's pathetic (e.g. strcpy()). While in theory applications should not depend on platform implementation issues like the direction of stack growth, in practice there are always some that break. (I think HPPA did go the upwards-growing stack way after all, and there have been quite a few problems surfacing ...) True, and we've certainly seen a few bugs in Linux kernel modules that accidentally worked on Intel and didn't on S/390 because of the separate kernel and user address spaces. So that's a fair argument for conformity. Ross Patterson
Re: Probably the first published shell code example for Linux/390
At 15:03 10/31/2002 -0500, Greg Smith wrote: I understand that much but why did Intel want you to use a top-down stack ?? Because electrical engineers and computer designers stand on each others shoulders, just like mathemeticians. The DEC PDP-11 stack grew down (heck, I think the -7 did too), and everyone who learned the Maynard, MA style of design followed it. I remember from my Pascal days that you could reference your caller's local variables, so I guess it's easier to reference them in a top-down stack. That's certainly true, although GCC can't claim the same reason. GCC goes way back before the Intel platform became it's most common target, and the early machines it ran on supported *signed* stack offsets! So reaching down was just as easy as up. Ross Patterson
Re: Probably the first published shell code example for Linux/390
At 13:10 10/31/2002 -0600, Ward, Garry wrote: push something to the stack, decrement the address, and if you've gone negative, you've gone too far? Sure, and the same is true of upwards-growing stacks (only in the other direction, natch). The issue isn't accidental stack overflow. The difference is in the impact of storage overlays - if your stack grows down, the memory above the current stack frame is your caller's. If your stack grows up, the memory above it is your callee's. Now imagine storing 1000 bytes into a 10-byte buffer on the stack (the classic shellcode-insertion hack). In the grows-down case, you overlay some active memory including possibly the savearea containing the register's you're going to reload when you hit the return statement. In the grows-up case, you overlay some inactive memory. sorry, PC assembler is a long time past, but I vaguely remember the argument being made that top down stacking was easier to manage. That's true on platforms that actually have stacks (sometimes). The 8080 and it's descendants do, and Intel chose to grow them downwards. It's a design issue, just like little-endian-ness, and IMHO just as wrong. :-) S/390 doesn't have a general-purpose hardware stack, so it's a matter of implementation preference. Ross Patterson
Re: Probably the first published shell code example for Linux/390
On Fri, 1 Nov 2002 03:10, you wrote: PUSH DEC BN stack overrun BZ stack overrun sorry, PC assembler is a long time past, but I vaguely remember the argument being made that top down stacking was easier to manage. AIR pop push don't affect the flags except then they're the target, and then the flags' new value is entirely what was on the stack. I would expect in either direction, passing 0 or -1 would be a valid cause of machine check or equivalent. -- Cheers John Summerfield Microsoft's most solid OS: http://www.geocities.com/rcwoolley/ Join the Linux Support by Small Businesses list at http://mail.computerdatasafe.com.au/mailman/listinfo/lssb
Probably the first published shell code example for Linux/390
Time to get aware of security concerns about Linux on 390. The last issue of the phrack magazine (a famous hacker magazine) has an article on how to write a shellcode on the Linux 390 platform with a complete working example. Here is the URL of the article about the shellcode: http://www.phrack.org/show.php?p=59a=130 I have tested it and seems to works fine. With such pieces of code also the 390 platform (with Linux on it) can be really open to external attacker (if they get in). Franco Fiorese EDS Italy
Re: Probably the first published shell code example for Linux/390
I was about to comment but after 35 years in the field , all I can say is OH WELL
Re: Probably the first published shell code example for Linux/390
Greetings; They key phrase here is (if they get in). The article itself isn't even up to the Assembler For Dummies level and doesn't reveal any great secrets about getting into the system. This is just the latest in a long string of writings by someone who doesn't know much about S/390 systems for others who don't know anything about S/390 systems. All it does is increase the authors prestige among his peers and spread FUD amongst the uninformed. Now, if the article detailed an exploit of a buffer overrun in Apache or Websphere on Linux/390 that would allow execution of rm -r / as root, that would be cause for alarm! Good Luck! Dennis |+- || Franco Fiorese | || [EMAIL PROTECTED]| || uzione.it | || Sent by: Linux on 390 Port | || [EMAIL PROTECTED] | || | || | || 10/30/02 02:14 PM | || Please respond to Linux on 390 | || Port | || | |+- ---| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Probably the first published shell code example for Linux/390 | ---| Time to get aware of security concerns about Linux on 390. The last issue of the phrack magazine (a famous hacker magazine) has an article on how to write a shellcode on the Linux 390 platform with a complete working example. Here is the URL of the article about the shellcode: http://www.phrack.org/show.php?p=59a=130 I have tested it and seems to works fine. With such pieces of code also the 390 platform (with Linux on it) can be really open to external attacker (if they get in). Franco Fiorese EDS Italy
Re: Probably the first published shell code example for Linux/390
On Wednesday, 10/30/2002 at 08:33 CST, Dennis Wicks [EMAIL PROTECTED] wrote: Greetings; They key phrase here is (if they get in). The article itself isn't even up to the Assembler For Dummies level and doesn't reveal any great secrets about getting into the system. This is just the latest in a long string of writings by someone who doesn't know much about S/390 systems for others who don't know anything about S/390 systems. All it does is increase the authors prestige among his peers and spread FUD amongst the uninformed. Now, if the article detailed an exploit of a buffer overrun in Apache or Websphere on Linux/390 that would allow execution of rm -r / as root, that would be cause for alarm! As Resident VM Security Guy, let me encourage you to stay on top of security updates, whether for IBM products or Linux. The hacking of Linux on the mainframe has begun (began a while back, in fact). The fact that S/390 is relatively unknown to general Hackerdom simply, I think, increases the prestige. It's another tech hurdle to jump and on the other side is Mainframe and Big Businesstempting targets. It's yet another reason to get a Linux support contract. Alan Altmark Sr. Software Engineer IBM z/VM Development
Re: Probably the first published shell code example for Linux/390
good point
Re: Probably the first published shell code example for Linux/390
Ron, I admire efforts to reduce wasted bandwidth, but I think you trimmed a bit too much from the post to which you're referring. Unrelated to that... I tried to get to the phrack site, and got our THE SITE YOU HAVE TRIED TO ACCESS IS RESTRICTED BY company name SECURITY ADMINISTRATOR. from our corporate firewall. g I guess I'll have to check it out when I get home. -jcf - Original Message - From: Ronald Wells [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, October 30, 2002 9:29 AM Subject: Re: Probably the first published shell code example for Linux/390 good point
Re: Probably the first published shell code example for Linux/390
And the key point here is that getting in simply requires modifying known exploits against vulnerable software with an S/390-specific payload. Now that the discussion has begun in the cracker world, it will not be long before we start seeing that happen. How many of the readers of this mailing list are still running a version of Apache that is accessible from the internet and doesn't have the chunk encoding fix installed? Every last one of those is vulnerable to a remote attack. We all have to keep in mind that the security systems we're used to having protect us, such as RACF, ACF2, VM Secure, etc., aren't at work in the Linux/390 world, in most cases. This is UNIX/Linux software requiring the same attention to security fixes as the rest of the UNIX/Linux world. Mark Post -Original Message- From: Dennis Wicks [mailto:dennisw;cdg.ws] Sent: Wednesday, October 30, 2002 9:34 AM To: [EMAIL PROTECTED] Subject: Re: Probably the first published shell code example for Linux/390 Greetings; They key phrase here is (if they get in). The article itself isn't even up to the Assembler For Dummies level and doesn't reveal any great secrets about getting into the system. This is just the latest in a long string of writings by someone who doesn't know much about S/390 systems for others who don't know anything about S/390 systems. All it does is increase the authors prestige among his peers and spread FUD amongst the uninformed. Now, if the article detailed an exploit of a buffer overrun in Apache or Websphere on Linux/390 that would allow execution of rm -r / as root, that would be cause for alarm! Good Luck! Dennis |+- || Franco Fiorese | || [EMAIL PROTECTED]| || uzione.it | || Sent by: Linux on 390 Port | || [EMAIL PROTECTED] | || | || | || 10/30/02 02:14 PM | || Please respond to Linux on 390 | || Port | || | |+- --- | | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Probably the first published shell code example for Linux/390 | --- | Time to get aware of security concerns about Linux on 390. The last issue of the phrack magazine (a famous hacker magazine) has an article on how to write a shellcode on the Linux 390 platform with a complete working example. Here is the URL of the article about the shellcode: http://www.phrack.org/show.php?p=59a=130 I have tested it and seems to works fine. With such pieces of code also the 390 platform (with Linux on it) can be really open to external attacker (if they get in). Franco Fiorese EDS Italy
Re: Probably the first published shell code example for Linux/390
or use Debian and run apt-get update; apt-get upgrade every day. On stable all you will get is security updates. If you want to review the fixes before installing them use --download-only on the upgrade and then you can install them at your leasure and have them downloaded ready for you every morning (if there are any that day). David Alan Altmark Alan_Altmark@uTo: [EMAIL PROTECTED] s.ibm.com cc: Sent by: Linux Subject: Re: Probably the first published shell code example on 390 Portfor Linux/390 [EMAIL PROTECTED] ARIST.EDU 30/10/2002 15:10 Please respond to Linux on 390 Port On Wednesday, 10/30/2002 at 08:33 CST, Dennis Wicks [EMAIL PROTECTED] wrote: Greetings; They key phrase here is (if they get in). The article itself isn't even up to the Assembler For Dummies level and doesn't reveal any great secrets about getting into the system. This is just the latest in a long string of writings by someone who doesn't know much about S/390 systems for others who don't know anything about S/390 systems. All it does is increase the authors prestige among his peers and spread FUD amongst the uninformed. Now, if the article detailed an exploit of a buffer overrun in Apache or Websphere on Linux/390 that would allow execution of rm -r / as root, that would be cause for alarm! As Resident VM Security Guy, let me encourage you to stay on top of security updates, whether for IBM products or Linux. The hacking of Linux on the mainframe has begun (began a while back, in fact). The fact that S/390 is relatively unknown to general Hackerdom simply, I think, increases the prestige. It's another tech hurdle to jump and on the other side is Mainframe and Big Businesstempting targets. It's yet another reason to get a Linux support contract. Alan Altmark Sr. Software Engineer IBM z/VM Development
Re: Probably the first published shell code example for Linux/390
On Wed, 2002-10-30 at 16:08, Post, Mark K wrote: We all have to keep in mind that the security systems we're used to having protect us, such as RACF, ACF2, VM Secure, etc., aren't at work in the Linux/390 world, in most cases. This is UNIX/Linux software requiring the same attention to security fixes as the rest of the UNIX/Linux world. Out of curiosity has anyone tried the Linux patches for RSBAC and/or NSA SELinux (Debian actually has packages for some of this stuff now btw) on an S/390
Re: Probably the first published shell code example for Linux/390
Alan, I haven't. But SELinux is another one of those some day I'd like to things. :( Mark Post -Original Message- From: Alan Cox [mailto:alan;lxorguk.ukuu.org.uk] Sent: Wednesday, October 30, 2002 2:38 PM To: [EMAIL PROTECTED] Subject: Re: Probably the first published shell code example for Linux/390 On Wed, 2002-10-30 at 16:08, Post, Mark K wrote: We all have to keep in mind that the security systems we're used to having protect us, such as RACF, ACF2, VM Secure, etc., aren't at work in the Linux/390 world, in most cases. This is UNIX/Linux software requiring the same attention to security fixes as the rest of the UNIX/Linux world. Out of curiosity has anyone tried the Linux patches for RSBAC and/or NSA SELinux (Debian actually has packages for some of this stuff now btw) on an S/390
Re: Probably the first published shell code example for Linux/390
This is the first time my innocent eyes have been tempted to look in this direction... I find it amusing that the technique requires masking x'00' and x'0A' - I'd think that no matter what platform, you'd have this problem when cramming binary stuff down the system's throat. Mission Impossible theme playing softly in the background I suppose to these folks, it's just another hoop to gleefully jump through to get the job done. sigh All that wasted energy and talent. -jcf [Thanks, MKP, for sending me this fine publication from which our corporate firewall protects me. Of course, this made me waste valuable company time perusing it. You just indirectly contributed to the rising cost of healthcare.]
Re: Probably the first published shell code example for Linux/390
Regarding credit for reducing healthcare costs... I'd gladly give you credit, but first, we'd have to USE such a system for at least one mission-critical application. In the words of our computer systems steering committee regarding Linux, Additional operating systems would not only further dilute our current capabilities, but would also require an investment that would prove to be cost prohibitive, exceeding possible benefits to the business. They prefer the reliability, flexibility, manageability and low low TCO of Microsoft products, from server to desktop. So rather than spend my time writing Perl scripts on Apache servers, it's VBScript and Outlook Forms on Exchange servers for me! There... I admitted it. :-( -jcf - Original Message - From: Post, Mark K [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, October 30, 2002 3:22 PM Subject: Re: Probably the first published shell code example for Linux/390 Ah, but it's not binary stuff, which is why the masking is necessary. x'00' = end of string and x'0a' = line feed, so ASCII bash scripts that are going to be executed can't have them embedded directly. As far as being an indirect cause of rising healthcare costs, do I also get the credit for reducing them when one of your systems is _not_ cracked? :)
Re: Probably the first published shell code example for Linux/390
Ah, but it's not binary stuff, which is why the masking is necessary. x'00' = end of string and x'0a' = line feed, so ASCII bash scripts that are going to be executed can't have them embedded directly. As far as being an indirect cause of rising healthcare costs, do I also get the credit for reducing them when one of your systems is _not_ cracked? :) Mark Post -Original Message- From: John Ford [mailto:zjcf;ChezFord.com] Sent: Wednesday, October 30, 2002 3:54 PM To: [EMAIL PROTECTED] Subject: Re: Probably the first published shell code example for Linux/390 This is the first time my innocent eyes have been tempted to look in this direction... I find it amusing that the technique requires masking x'00' and x'0A' - I'd think that no matter what platform, you'd have this problem when cramming binary stuff down the system's throat. Mission Impossible theme playing softly in the background I suppose to these folks, it's just another hoop to gleefully jump through to get the job done. sigh All that wasted energy and talent. -jcf [Thanks, MKP, for sending me this fine publication from which our corporate firewall protects me. Of course, this made me waste valuable company time perusing it. You just indirectly contributed to the rising cost of healthcare.]
Re: Probably the first published shell code example for Linux/390
At 11:08 10/30/2002 -0500, Post, Mark K wrote: And the key point here is that getting in simply requires modifying known exploits against vulnerable software with an S/390-specific payload. But it didn't have to be this way. If Linas Vepstas et al. had been able to finish the Bigfoot i370 port or if his attempts to influence the IBM s390 port had been successful, we wouldn't have this problem. Linas' port of GCC for Bigfoot had the stack growing *upward*, not *downward* as on almost every other platform. Almost half of the CERT vulnerabilities since 1 Jan 2000 are due to buffer overruns (even more if you assume multiple vulnerabilities includes some). And most of these buffer overruns are actually stack overruns, allowing the creative cracker to change things like where the current subroutine will return to (in particular, to code that does evil things like the phrack shellcode example). It's kind of hard to overwrite your caller's stack frame when it's at a lower address than yours. Linas explained it nicely almost two years ago right here: http://www.marist.edu:8000/htbin/wlvtype?LINUX-VM.1315. Ross Patterson
Re: Probably the first published shell code example for Linux/390
On Thu, 31 Oct 2002 00:01, you wrote: I admire efforts to reduce wasted bandwidth, but I think you trimmed a bit too much from the post to which you're referring. Unrelated to that... I tried to get to the phrack site, and got our THE SITE YOU HAVE TRIED TO ACCESS IS RESTRICTED BY company name SECURITY ADMINISTRATOR. from our corporate firewall. g I guess I'll have to check it out when I get home. So much for coporate censorship! -- Cheers John Summerfield Microsoft's most solid OS: http://www.geocities.com/rcwoolley/ Join the Linux Support by Small Businesses list at http://mail.computerdatasafe.com.au/mailman/listinfo/lssb
