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
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
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
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
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
-
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
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
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
] [[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
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
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
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
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
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
: 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
.
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
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
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
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
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
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
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
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
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:
I was about to comment but after 35 years in the field , all I can say is
OH WELL
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
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
good point
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
: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
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
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
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
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
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
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
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
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
38 matches
Mail list logo
