'FUNCTION: To save the programmer effort by automatically incorporating library subroutines into the source program.'in Cobol whole 'functions' (subroutines) and even code snipplets are 'copied' into the main source file by the copy statement. That's different to preprocessor macros, -definitions, -literals and, since ansi c, function prototypes.
'FUNCTION: To save the programmer effort by automatically incorporating library subroutines into the source program.'in Cobol whole 'functions' (subroutines) and even code snipplets are 'copied' into the main source file by the copy statement. That's different to preprocessor macros, -definitions, -literals and, since ansi c, function prototypes.
Dear all,
I am starting a new “history” section of the “weird machines and security” publication PoC||GTFO (https://www.alchemistowl.org/pocorgtfo for my mirror, https://www.nostarch.com/gtfo for a printed compilation of the first 15 issues).
Ideally we would like some articles about the history of security exploits where the historical importance is emphasised: we always get authors willing to tell us about the latest and greatest web exploit but they often lack any historical perspective about what has been done before.
As PoC||GTFO has a strong emphasis on weird machines and generally forgotten hardware and software I thought that the contributors to TUHS would be ideally placed to write something about their preferred security exploits in the past. I have fond memories of taking over a machine using and NFS /home filesystem exported to the wide-world, of someone trying to hack into my MasPar via the DEC Ultrix which controlled it, etc. but I am really rather interested in other perspectives.
I hope a few of you will want to contribute something to the collection, there is still space for the January 2018 edition if anyone is so inclined.
Cheers,
Arrigo
I apologise if this is too far from the main topic, but I wanted to check
an urban legend.
There is a story - as I have heard it told - that PDPs established their
place (and popularity) in the marketplace by pointedly *not* advertising
themselves as "computers", but instead as "programmed data processors".
This was because - so the story goes - that everyone in corporations of the
time simply *knew* that "computers" came only from IBM, lived in big
datacentres, had million-dollar price-tags, and required extensive project
management to purchase; whereas nobody cared enough about a thing called a
"programmed data processor" to bother bikeshedding the
few-tens-or-hundreds-of-thousands-of-dollars purchase proposal to an
inevitable death. Thus, they flitted under the purchasing radar, and sold
like hotcakes.
I wonder: does this story have substance, please?
Aside from anything else: I draw parallels to the adoption of Linux by Wall
St, and the subsequent adoption of virtualisation / AWS by business - now
reflected in companies explaining to ISO27001 auditors that "well, we don't
actually possess any physical servers..."
- alec
--
http://dropsafe.crypticide.com/aboutalecm
I think that steep educational discounts and equipment grants from Digital to major collages also had a major impact,as did the existence of DECUS that made a lot of software readily available.
Best regards,
David Ritchie
Charles Babbage KH FRS was born on this day in 1791; pretty much the
father of the computer, a model of his "difference engine" built to the
standards of the day worked, complete with its printer. What is not so
well known about him was that he dabbled in cryptography, and broke the
Vigenère cipher; unfortunately for him it was classified as a military
secret, so one Friedrich Kasiski got the credit instead.
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
Somewhat tangentially related to the other thread...
So, back in the days when I was using Consensys SVR4.2, I found a bug in
tar. It goes like this:
If there is a symbolic link in the tree that you are taring, the first
one works fine. If a second symbolic link has a shorter destination name
than the first, the extra characters from the first symbolic link
destination are appended to the end of the second. So for example:
a -> abcdef
b -> zyx
Tar will actually tar these symbolic links as:
a -> abcdef
b -> zyxdef
Being that I happen to have found, on the Internet, the sources to AT&T
SVR4.2, and some other System V variants, I went and investigated.
The relevant piece from AT&T SVR4.2 tar.c (broken):
Jan 25 1993 ./ATT/ATT-SYSVr4/cmd/tar/tar.c
case S_IFLNK:
<SNIP>
i = readlink(shortname, filetmp, NAMSIZ - 1);
if (i < 0) {
vperror(0, "can't read symbolic link %s",
longname);
return;
}
From USL-4.2 (apparently fixed):
Jan 22 1994 ./USL/usl-4.2-source/src/i386/cmd/tar/tar.c
case S_IFLNK:
<SNIP>
i = readlink(shortname, filetmp, NAMSIZ - 1);
if (i < 0) {
vperror(0, ":462:Cannot read symbolic link %s",
longname);
return;
}
else
filetmp[i] = '\0'; /* since readlink does not
supply a '\0' */
From Solaris 2.5:
case S_IFLNK:
<SNIP>
i = readlink(shortname, filetmp, NAMSIZ - 1);
if (i < 0) {
vperror(0, gettext(
"can't read symbolic link %s"), longname);
if (aclp != NULL)
free(aclp);
return;
} else {
filetmp[i] = 0;
}
BSD 4.4:
case S_IFLNK:
<SNIP>
i = readlink(shortname, dblock.dbuf.linkname, NAMSIZ - 1);
if (i < 0) {
fprintf(stderr,
"tar: can't read symbolic link %s: %s\n",
longname, strerror(errno));
return;
}
dblock.dbuf.linkname[i] = '\0';
Anyone know when/why/how tar diverged between the two branches? Note the
readlink directly into dblock.dbuf, while the SVR4 variants use a temp
string and then sprintf it in later.
From: http://www.catb.org/esr/faqs/usl-bugs.txt
17. tar(1) fails to restore adjacent symbolic links properly
Arthur Krewatt <...!rutgers!mcdhup!kilowatt!krewat> reports:
SVR4 tar has another strange bug. Seems if when restoring files, you
restore one file that is a link, say "a ->/a/b/c/d/e" and there is another
link just after it called "b ->/a/b/c" tar will restore it as "b ->/a/b/c/d/e"
This just seems to be a lack of the NULL at the end of the string, like
someone did a memmov or memcpy(dest,src,strlen(src)); where it should be
strlen(src)+1 to include the NULL.
Esix cannot reproduce this under 4.0.4 or 4.0.4.1, they think it's fixed.
Hello Team TUHS:
I am having a problem with my PDP-11 SVR1 running under a recent SIMH build. My problem occurs on both MAC OS X and FreeBSD.
First, I created a six disk (RP06) and eight port TTY (DZ) kernel, with swap placed on drive 1. The system behaves beautifully as FSCK reports clean. Eight users can login with no problem.
Second, I reverted to a pristine PDP-11 SVR1 with one drive (RP06) and no DZ and booted the default kernel (gdtm) and I see the same problem described below.
Third, when using the tape driver instead of /dev/null i get the same results.
Next, here is the issue:
cd /
find . -print | cpio -ocvB > /dev/null
It runs for a short while and then shitz a core:
I am using /dev/null to take the tape driver out of the equation.
Here is the backtrace for cpio:
$c
__strout(053522,043,0,053012)
__doprnt(046652,0177606,053012)
_fprintf(053012,046652,053522)
~main(02,0177636)
Now, interestingly, I run into a similar issue when using tar:
cd /usr
tar -cvf /dev/null .
Again, this will run for a while, then drops a core. Here is the backtrace for tar:
$c
__strout(043123,02,0,045506)
__doprnt(043123,0167472,045506)
_fprintf(045506,043123,0170600)
~putfile(0170600,0170641)
~putfile(0171654,0171704)
~putfile(0172730,0172745)
~putfile(0174004,0174016)
~putfile(0175060,0175066)
~putfile(0176134,0176136)
~putfile(0177672,0177672)
~dorep(0177632)
~main(04,0177630)
This really bugging me since my SVR1 is otherwise working flawlessly. I was able to remake the entire system and custom kernels that boot with no problem.
Also, I configured my main port to run inside the AWS Lightsail and now I have access to SVR1 from anywhere in the world!
I was also wondering if doing a CPIO or TAR on the entire system was overflowing some link tables and maybe this is expected behavior for the minimal resource of the PDP-11?
Thank you for any help.
Would you expect tar or cpio to dump core if you attempted to copy large filesystems (or the entire system) on a PDP-11?
Note: All of my testing has been in single user mode.
Truly,
Bill Corcoran
> From: Dave Horsfall
> Colossus, arguably the world's first electronic computer
Well, it all depends on your definition of "computer"... :-)
I myself prefer to reserve that term for things that are programmable,
and Turing-complete. (YMMV... :-)
So I call things like Colossus and ABC "digital electronic calculating
devices" (or something similar).
None of which is to take anything away from the incredible job done by Flowers
and his cohorts. It was an amazing device, and had a major effect on history.
Noel
