Another Reason To Go 64-Bit

Discussion in 'NZ Computing' started by Lawrence D'Oliveiro, Mar 2, 2010.

  1. Makes it harder for exploiters of buffer-overflow attacks to predict which
    addresses to find things at <http://blogs.zdnet.com/security/?p=5573>.
    Lawrence D'Oliveiro, Mar 2, 2010
    #1
    1. Advertising

  2. Lawrence D'Oliveiro

    Matty F Guest

    On Mar 2, 3:00 pm, Lawrence D'Oliveiro <l...@geek-
    central.gen.new_zealand> wrote:
    > Makes it harder for exploiters of buffer-overflow attacks to predict which
    > addresses to find things at <http://blogs.zdnet.com/security/?p=5573>.


    What the hell is buffer-overflow except exceedingly bad programming
    that we learned to totally avoid in the 1970s?
    Matty F, Mar 2, 2010
    #2
    1. Advertising

  3. In message <cb74fb62-
    >, Matty F wrote:

    > What the hell is buffer-overflow except exceedingly bad programming
    > that we learned to totally avoid in the 1970s?


    Surprisingly tricky to avoid: see if you can figure out what this patch is
    guarding against <http://marc.info/?l=bugtraq&m=103564944215101&w=2>.
    Lawrence D'Oliveiro, Mar 2, 2010
    #3
  4. On Tue, 02 Mar 2010 21:01:20 +1300, Lawrence D'Oliveiro
    <_zealand> wrote:

    >In message <cb74fb62-
    >>, Matty F wrote:
    >
    >> What the hell is buffer-overflow except exceedingly bad programming
    >> that we learned to totally avoid in the 1970s?

    >
    >Surprisingly tricky to avoid: see if you can figure out what this patch is
    >guarding against <http://marc.info/?l=bugtraq&m=103564944215101&w=2>.


    I always like the way the old Burroughs B6700 mainframe I learned on
    did things. It was a tagged architecture, and used hardware
    descriptors for everything. So when you allocated an array, you got a
    hardware descriptor to access it. And the descriptor had the length
    in it and if you accessed outside the memory pointed to by the
    descriptor, you got a hardware check that killed your program. There
    was no way to tamper with the descriptors, because the hardware tags
    on them said they were read only - again, the hardware killed the
    program on any attempt to write to them. Stacks, like any other
    storage, were accessed via a descriptor also, and hence you could not
    overflow them either. Simple and very bulletproof compared to most
    hardware in use today.
    Stephen Worthington, Mar 3, 2010
    #4
  5. In message <>, Stephen Worthington
    wrote:

    > I always like the way the old Burroughs B6700 mainframe I learned on
    > did things. It was a tagged architecture, and used hardware
    > descriptors for everything.


    It also relied on the software to enforce system protections. Get access to
    a compiler that could generate privileged code, and you could take over the
    system.

    The last few jobs I did that involved secure communication over the
    (potentially hostile) Internet, I decided to construct the protocol out of
    pieces that were as simple as possible. Basically, anything variable-length
    had exactly the same format. That way I could write just one or two pieces
    of low-level parsing code, that I could be sure were carefully coded to
    avoid being fooled by bogus length fields and what not. Then I could build
    arbitrarily complex protocols on top of that, without having to worry about
    low-level data-corruption attacks.

    The basic scheme is described here
    <http://www.codecodex.com/wiki/Simple_Chunk_Protocol_Format>.
    Lawrence D'Oliveiro, Mar 3, 2010
    #5
  6. On Wed, 03 Mar 2010 17:58:10 +1300, Lawrence D'Oliveiro
    <_zealand> wrote:

    >In message <>, Stephen Worthington
    >wrote:
    >
    >> I always like the way the old Burroughs B6700 mainframe I learned on
    >> did things. It was a tagged architecture, and used hardware
    >> descriptors for everything.

    >
    >It also relied on the software to enforce system protections. Get access to
    >a compiler that could generate privileged code, and you could take over the
    >system.


    Yes, but access to the system Algol compiler was very restricted. You
    needed to be a sysop to run it, and if you managed to get a sysop
    login you could do anything anyway, including designating user
    programs as system executables. Just like root today.
    Stephen Worthington, Mar 3, 2010
    #6
  7. Lawrence D'Oliveiro

    Sweetpea Guest

    On Wed, 03 Mar 2010 14:20:10 +1300, Stephen Worthington wrote:

    >>> What the hell is buffer-overflow except exceedingly bad programming
    >>> that we learned to totally avoid in the 1970s?


    Microsoft DOS, MS Windows, and MS WindowsNT were written in the 80s and early 90s. There have
    been countless security exploits in that code base in the intervening years. There may yet be other
    buffer over-run security flaws that either M$ has not disclosed or it is still not even aware that they exist.

    Windows "7" is still fundamentally WinNT "3" in its core but with multiple facelifts and at least one heart-
    lung transplant attempting to excise the cancer.

    Unfortunately MS WindowsNT is utterly riddled, and the most humane thing to do would be to
    euthanize it. and move on to something that is more likely to survive.


    --
    "Filtering the Internet is like trying to boil the ocean"
    Sweetpea, Mar 3, 2010
    #7
  8. Lawrence D'Oliveiro

    Sweetpea Guest

    On Wed, 03 Mar 2010 20:47:34 +1300, Stephen Worthington wrote:

    > On Wed, 03 Mar 2010 17:58:10 +1300, Lawrence D'Oliveiro
    > <_zealand> wrote:
    >
    >>In message <>, Stephen
    >>Worthington wrote:
    >>
    >>> I always like the way the old Burroughs B6700 mainframe I learned on
    >>> did things. It was a tagged architecture, and used hardware
    >>> descriptors for everything.

    >>
    >>It also relied on the software to enforce system protections. Get access
    >>to a compiler that could generate privileged code, and you could take
    >>over the system.

    >
    > Yes, but access to the system Algol compiler was very restricted. You
    > needed to be a sysop to run it, and if you managed to get a sysop login
    > you could do anything anyway, including designating user programs as
    > system executables. Just like root today.


    That's because most tasks were run by Systems Operators or Systems Administrators and not by users.


    --
    "Filtering the Internet is like trying to boil the ocean"
    Sweetpea, Mar 3, 2010
    #8
  9. In message <>, Stephen Worthington
    wrote:

    > On Wed, 03 Mar 2010 17:58:10 +1300, Lawrence D'Oliveiro
    > <_zealand> wrote:
    >
    >>In message <>, Stephen
    >>Worthington wrote:
    >>
    >>> I always like the way the old Burroughs B6700 mainframe I learned on
    >>> did things. It was a tagged architecture, and used hardware
    >>> descriptors for everything.

    >>
    >>It also relied on the software to enforce system protections. Get access
    >>to a compiler that could generate privileged code, and you could take over
    >>the system.

    >
    > Yes, but access to the system Algol compiler was very restricted. You
    > needed to be a sysop to run it ...


    Oh, really?

    I was told by a colleague who use Burroughs systems in his student days,
    that he was able to get hold of a tape containing such privileged software,
    and then it was just a matter of tricking the operator into mounting it for
    him to access. Once that happened, he was in.
    Lawrence D'Oliveiro, Mar 3, 2010
    #9
  10. Lawrence D'Oliveiro

    Matty F Guest

    On Mar 2, 9:01 pm, Lawrence D'Oliveiro <l...@geek-
    central.gen.new_zealand> wrote:
    > In message <cb74fb62-
    >
    > >, Matty F wrote:
    > > What the hell is buffer-overflow except exceedingly bad programming
    > > that we learned to totally avoid in the 1970s?

    >
    > Surprisingly tricky to avoid: see if you can figure out what this patch is
    > guarding against <http://marc.info/?l=bugtraq&m=103564944215101&w=2>.


    "This length field is not checked" - why ever not? Incoming data
    should always be checked if invalid data could cause a problem.
    Matty F, Mar 3, 2010
    #10
  11. On Wed, 3 Mar 2010 08:59:07 +0000 (UTC), Sweetpea
    <> wrote:

    >On Wed, 03 Mar 2010 20:47:34 +1300, Stephen Worthington wrote:
    >
    >> On Wed, 03 Mar 2010 17:58:10 +1300, Lawrence D'Oliveiro
    >> <_zealand> wrote:
    >>
    >>>In message <>, Stephen
    >>>Worthington wrote:
    >>>
    >>>> I always like the way the old Burroughs B6700 mainframe I learned on
    >>>> did things. It was a tagged architecture, and used hardware
    >>>> descriptors for everything.
    >>>
    >>>It also relied on the software to enforce system protections. Get access
    >>>to a compiler that could generate privileged code, and you could take
    >>>over the system.

    >>
    >> Yes, but access to the system Algol compiler was very restricted. You
    >> needed to be a sysop to run it, and if you managed to get a sysop login
    >> you could do anything anyway, including designating user programs as
    >> system executables. Just like root today.

    >
    >That's because most tasks were run by Systems Operators or Systems Administrators and not by users.


    Not true. We had lots (for those days) of terminals that were used by
    senior students and staff to run jobs themselves. The junior student
    jobs were actually run on a special sub-OS that the staff had written
    that even further restricted what access they had (SOBS = Student
    Oriented Batch System, IIRC). All those jobs had to be submitted on
    card decks. It was always a problem to be able to get one of the card
    punch machines that allowed you to edit within a line, otherwise if
    you had to use one of the old punch as you go machines you were there
    for ages repunching mistakes in your typing.
    Stephen Worthington, Mar 3, 2010
    #11
  12. On Wed, 03 Mar 2010 22:04:41 +1300, Lawrence D'Oliveiro
    <_zealand> wrote:

    >In message <>, Stephen Worthington
    >wrote:
    >
    >> On Wed, 03 Mar 2010 17:58:10 +1300, Lawrence D'Oliveiro
    >> <_zealand> wrote:
    >>
    >>>In message <>, Stephen
    >>>Worthington wrote:
    >>>
    >>>> I always like the way the old Burroughs B6700 mainframe I learned on
    >>>> did things. It was a tagged architecture, and used hardware
    >>>> descriptors for everything.
    >>>
    >>>It also relied on the software to enforce system protections. Get access
    >>>to a compiler that could generate privileged code, and you could take over
    >>>the system.

    >>
    >> Yes, but access to the system Algol compiler was very restricted. You
    >> needed to be a sysop to run it ...

    >
    >Oh, really?
    >
    >I was told by a colleague who use Burroughs systems in his student days,
    >that he was able to get hold of a tape containing such privileged software,
    >and then it was just a matter of tricking the operator into mounting it for
    >him to access. Once that happened, he was in.


    Exactly, it required a sysop to run the job from the tape. Of course,
    the sysops were busy people who made mistakes at times and could have
    been fooled into loading a tape and allowing it to run jobs. And once
    you have broken through the security by getting the weakest link to
    fail, then you can get to do whatever you want. But in the case of
    the B6700s, the weakest link was the humans, not the computer or
    software architecture.

    The Intel architecture was well outdated when it was invented, but
    when the 8086 was born, but Intel made a useful processor that fit in
    the abilities of the silicon available back then. Then IBM made the
    PC and it all took off - much to my horror. IBM should have chosen a
    better chip. And Intel started down the path of wanting always to
    keep new chips compatible with the old ones, so now the architecture
    is incredibly awful and overgrown. And Microsoft have capped that off
    by making their OS even worse than the Intel architecture. It should
    have all been killed off at birth, or as soon as possible afterwards,
    in favour of something that was properly designed. We knew how to do
    it properly well before the Wintel architecture happened.
    Stephen Worthington, Mar 3, 2010
    #12
  13. In message <>, Matty F wrote:

    > On Mar 2, 9:01 pm, Lawrence D'Oliveiro <_zealand>
    > wrote:
    >
    >> In message <>,
    >> Matty F wrote:
    >>
    >>> What the hell is buffer-overflow except exceedingly bad programming
    >>> that we learned to totally avoid in the 1970s?

    >>
    >> Surprisingly tricky to avoid: see if you can figure out what this patch
    >> is guarding against <http://marc.info/?l=bugtraq&m=103564944215101&w=2>.

    >
    > "This length field is not checked" - why ever not? Incoming data
    > should always be checked if invalid data could cause a problem.


    Which was not obvious for a long time.

    There was also another case, where the length field was checked, but in a
    way that could be defeated if certain values were passed in that triggered
    integer overflow.
    Lawrence D'Oliveiro, Mar 3, 2010
    #13
  14. Lawrence D'Oliveiro

    Sweetpea Guest

    On Wed, 03 Mar 2010 23:12:22 +1300, Stephen Worthington wrote:

    >>That's because most tasks were run by Systems Operators or Systems
    >>Administrators and not by users.

    >
    > Not true. We had lots (for those days) of terminals that were used by
    > senior students and staff to run jobs themselves.


    So there were certain commands that the Admins permitted users to be able to run.

    Most likely little different from being able to list the contents of a directory in terms of impact on
    performance.


    --
    "Filtering the Internet is like trying to boil the ocean"
    Sweetpea, Mar 3, 2010
    #14
  15. On Wed, 3 Mar 2010 18:23:58 +0000 (UTC), Sweetpea
    <> wrote:

    >On Wed, 03 Mar 2010 23:12:22 +1300, Stephen Worthington wrote:
    >
    >>>That's because most tasks were run by Systems Operators or Systems
    >>>Administrators and not by users.

    >>
    >> Not true. We had lots (for those days) of terminals that were used by
    >> senior students and staff to run jobs themselves.

    >
    >So there were certain commands that the Admins permitted users to be able to run.
    >
    >Most likely little different from being able to list the contents of a directory in terms of impact on
    >performance.


    The terminals had a command line just like a modern Linux one or
    Windows one. It could not do any of the SysOp commands (??? prefix)
    unless logged in as a SysOp user, but you could certainly compile and
    run programs. There was a job queue - if the B6700 was busy, your job
    might have to wait several minutes in the queue before it ran.
    Fortunately, you could just put a big job in the low priority queue
    and collect the results later.
    Stephen Worthington, Mar 4, 2010
    #15
  16. Lawrence D'Oliveiro

    Sweetpea Guest

    On Thu, 04 Mar 2010 13:01:49 +1300, Stephen Worthington wrote:

    > The terminals had a command line just like a modern Linux one or Windows
    > one. It could not do any of the SysOp commands (??? prefix) unless
    > logged in as a SysOp user, but you could certainly compile and run
    > programs.


    Entering any "command" that isn't a function of the shell runs a program.

    Even on a Unix box today some commands a user can run, and some commands are restricted to the
    root user.


    --
    "Filtering the Internet is like trying to boil the ocean"
    Sweetpea, Mar 4, 2010
    #16
  17. In message <>, Stephen Worthington
    wrote:

    > The terminals had a command line just like a modern Linux one or
    > Windows one.


    Windows one, maybe, Linux one, no.
    Lawrence D'Oliveiro, Mar 4, 2010
    #17
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. AeoN

    Yet another reason to switch to Firefox

    AeoN, Nov 6, 2004, in forum: Computer Support
    Replies:
    3
    Views:
    410
    Duane Arnold
    Nov 10, 2004
  2. Roberts
    Replies:
    5
    Views:
    4,395
    Stephen
    Nov 21, 2004
  3. Replies:
    14
    Views:
    661
    Evan Platt
    Mar 15, 2005
  4. Goro
    Replies:
    0
    Views:
    374
  5. Jim
    Replies:
    2
    Views:
    441
    James Robertson
    Sep 25, 2006
Loading...

Share This Page