And now we wait for other old OS'es to be tested for exploits...
1896 posts • joined 6 Jan 2010
I have to assume they will also cater for updates, especially to the kernel etc? And how to handle it, especially if it is a headerless server running in some inaccessible place.
Still remember the irritation of having to approve applications with some windows firewall/antivirus especially after windowsupdate did its thing (think it was zonealarm).
How many times would I told an user to "keep on saving your work, F2 (Turbo Pascal's shortcut to save) will do it"... only to have said user ignore my advice blithely, carry on typing a beautiful and perfectly working program, only to have the PC crash.... (It was my experience with programs and PC's to keep on saving frequently, especially when doing Turbo Assembler stuff. Back then there was no virtual machines).
v2 of the same program was buggy and full of errors. Shame. NOT.
Re: Just finger trouble
Hah, I played around with Smoothwall back then.
The tower case (which was the Smoothwall) was conveniently next to my work desk.
Daughter was crawling around all over the place, she saw the tall, white box with blinkenlights, and she did a gefingerpoken at the reset button.
Daddy was NOT amused :)
I disconnected the actual reset and power button cables from the motherboard, then set the motherboard's BIOS settings to turn itself on when power was restored.
Then it was simple - shut it down, it'll power off, and switch off at the wall. When I want to use it again, power on at the wall and the PC'll start up again.
Little fingers still poked the buttons afterwards, but nothing happened. :)
And expect problems and issues like this to start spreading like rot to other tablets, phablets, phones and other fondleslab thingies, because they all want to make it "smaller, thinner and flatter whatever", cramming more components per square mm which will generate more heat and cause more issues.
Myself, it does not bother me if the fondleslab device is a bit on the big and chunky side, to allow for proper cooling of the components.
Having the thinnest, flattest thing is totally overrated.
It should entirely be possible to get the location of the ne'er-do-well with extensive crossreffing from the wibbly wobbly webz, then lob a Tsar Bomba into said ne'er-do-well's general direction, which should stop spamz and general tomfoolery from said ne'er-do-well for good.
Of course, collateral damage and fallout may be a small issue...
Why is it that cheap laptops practically last next to forever, but the more expensive ones b0rk themselves just out of warranty?
Had a Gigabyte W565M laptop with Vista preinstalled - rock solid, surprisingly. Upgraded to Windows7, and it was even better. When the infamous Win10 upgrade trojan rolled around for a call, I blocked it with Never10 as I was happy with Win7.
Still is chugging along, a bit of a slowpoke in comparision to others, but what the hey, it still works, and doesn't have funky issues. Kids play their games on it, so it is still good for something. :)
Common sense tells that you issue new kit only after you have received the broken/defective/BOFH'd piece of kit...
This kind of shenanigans will make some vendor lock their processes down, making it more difficult for honest IT types to make a living, especially with a client (and large network base) down due to a borked server/switch/whatever which need to be exchanged first for a replacement before everything can be fixed, instead of getting a replacement first, getting the client up and running, and then sending the borked POS kit back to the supplier....
US Pentagon scrambles after Strava base leaks. Here's a summary of the new rules: 'Secure that s***, Hudson!'
OS/2 Warp LAN server any better? :p
Netware 3.12 was an absolute joy to admin and run, rock-solid and reliable until somebody get admin rights and allow a pesky DOS virus to overwrite all the DOS Netware apps and files :)
And ncsnipes! (it is an android app btw)
A file and printering server should be just that - file and printering server... not an application server, which should be something totally different and on different hardware.
But beancountery things want less servers in the server room, so it means one big, beefy PC to host multiple VM's, all with their own quirks and Spectre vulns...
Ahhh, which reminds me of this gem :
rm -rf / [folklore] [home] [search]
Such things happened at least once to every unix person... To me it happened on February 1, 2000, after several years of heavy Unix usage/administration, when I was damn confident in myself and just leniently smiled on all these for-clueless-newbies warnings about not doing things as root.
In the middle of the working day, being a root on the main NFS server containing all user homes, sitting in /home/some_user, I typed chown -R some_user .* and stopped it in 15-20 seconds when realized that something is going wrong. But you know, that server was really fast and permissions of the good half of the whole user space have been modified. (I recovered of course - by the price of my lunch time).
Anyway, the following classic article from Mario Wolczko describing much more interesting case first appeared on Usenet in 1986.
Have you ever left your terminal logged in, only to find when you came back to it that a (supposed) friend had typed rm -rf ~/* and was hovering over the keyboard with threats along the lines of "lend me a fiver 'til Thursday, or I hit return"? Undoubtedly the person in question would not have had the nerve to inflict such a trauma upon you, and was doing it in jest. So you've probably never experienced the worst of such disasters...
It was a quiet Wednesday afternoon. Wednesday, 1st October, 15:15 BST, to be precise, when Peter, an office-mate of mine, leaned away from his terminal and said to me, "Mario, I'm having a little trouble sending mail." Knowing that msg was capable of confusing even the most capable of people, I sauntered over to his terminal to see what was wrong. A strange error message of the form (I forget the exact details) "cannot access /foo/bar for userid 147" had been issued by msg. My first thought was "Who's userid 147?; the sender of the message, the destination, or what?" So I leant over to another terminal, already logged in, and typed grep 147 /etc/passwd only to receive the response /etc/passwd: No such file or directory. Instantly, I guessed that something was amiss. This was confirmed when in response to ls /etc I got ls: not found.
I suggested to Peter that it would be a good idea not to try anything for a while, and went off to find our system manager.
When I arrived at his office, his door was ajar, and within ten seconds I realised what the problem was. James, our manager, was sat down, head in hands, hands between knees, as one whose world has just come to an end. Our newly-appointed system programmer, Neil, was beside him, gazing listlessly at the screen of his terminal. And at the top of the screen I spied the following lines:
# rm -rf *
Oh, shit, I thought. That would just about explain it.
I can't remember what happened in the succeeding minutes; my memory is just a blur. I do remember trying ls (again), ps, who and maybe a few other commands beside, all to no avail. The next thing I remember was being at my terminal again (a multi-window graphics terminal), and typing
I owe a debt of thanks to David Korn for making echo a built-in of his shell; needless to say, /bin, together with /bin/echo, had been deleted. What transpired in the next few minutes was that /dev, /etc and /lib had also gone in their entirety; fortunately Neil had interrupted rm while it was somewhere down below /news, and /tmp, /usr and /users were all untouched.
Meanwhile James had made for our tape cupboard and had retrieved what claimed to be a dump tape of the root filesystem, taken four weeks earlier. The pressing question was, "How do we recover the contents of the tape?". Not only had we lost /etc/restore, but all of the device entries for the tape deck had vanished. And where does mknod live? You guessed it, /etc. How about recovery across Ethernet of any of this from another VAX? Well, /bin/tar had gone, and thoughtfully the Berkeley people had put rcp in /bin in the 4.3 distribution. What's more, none of the Ether stuff wanted to know without /etc/hosts at least. We found a version of cpio in /usr/local, but that was unlikely to do us any good without a tape deck.
Alternatively, we could get the boot tape out and rebuild the root filesystem, but neither James nor Neil had done that before, and we weren't sure that the first thing to happen would be that the whole disk would be re-formatted, losing all our user files. (We take dumps of the user files every Thursday; by Murphy's Law this had to happen on a Wednesday). Another solution might be to borrow a disk from another VAX, boot off that, and tidy up later, but that would have entailed calling the DEC engineer out, at the very least. We had a number of users in the final throes of writing up PhD theses and the loss of a maybe a weeks' work (not to mention the machine down time) was unthinkable.
So, what to do? The next idea was to write a program to make a device descriptor for the tape deck, but we all know where cc, as and ld live. Or maybe make skeletal entries for /etc/passwd, /etc/hosts and so on, so that /usr/bin/ftp would work. By sheer luck, I had a gnu emacs still running in one of my windows, which we could use to create passwd, etc., but the first step was to create a directory to put them in. Of course /bin/mkdir had gone, and so had /bin/mv, so we couldn't rename /tmp to /etc. However, this looked like a reasonable line of attack.
By now we had been joined by Alasdair, our resident UNIX guru, and as luck would have it, someone who knows VAX assembler. So our plan became this: write a program in assembler which would either rename /tmp to /etc, or make /etc, assemble it on another VAX, uuencode it, type in the uuencoded file using my gnu, uudecode it (some bright spark had thought to put uudecode in /usr/bin), run it, and hey presto, it would all be plain sailing from there. By yet another miracle of good fortune, the terminal from which the damage had been done was still su'd to root (su is in /bin, remember?), so at least we stood a chance of all this working.
Off we set on our merry way, and within only an hour we had managed to concoct the dozen or so lines of assembler to create /etc. The stripped binary was only 76 bytes long, so we converted it to hex (slightly more readable than the output of uuencode), and typed it in using my editor. If any of you ever have the same problem, here's the hex for future reference:
070100002c000000000000000000000000000000000000000000000000000000 0000dd8fff010000dd8f27000000fb02ef07000000fb01ef070000000000bc8f 8800040000bc012f65746300
I had a handy program around (doesn't everybody?) for converting ASCII hex to binary, and the output of /usr/bin/sum tallied with our original binary. But hang on - how do you set execute permission without /bin/chmod? A few seconds thought (which as usual, lasted a couple of minutes) suggested that we write the binary on top of an already existing binary, owned by me... problem solved.
So along we trotted to the terminal with the root login, carefully remembered to set the umask to 0 (so that I could create files in it using my gnu), and ran the binary. So now we had a /etc, writable by all. From there it was but a few easy steps to creating passwd, hosts, services, protocols, (etc), and then ftp was willing to play ball. Then we recovered the contents of /bin across the ether (it's amazing how much you come to miss ls after just a few, short hours), and selected files from /etc. The key file was /etc/rrestore, with which we recovered /dev from the dump tape, and the rest is history.
Now, you're asking yourself (as I am), what's the moral of this story? Well, for one thing, you must always remember the immortal words, DON'T PANIC. Our initial reaction was to reboot the machine and try everything as single user, but it's unlikely it would have come up without /etc/init and /bin/sh. Rational thought saved us from this one.
The next thing to remember is that UNIX tools really can be put to unusual purposes. Even without my gnuemacs, we could have survived by using, say, /usr/bin/grep as a substitute for /bin/cat.
And the final thing is, it's amazing how much of the system you can delete without it falling apart completely. Apart from the fact that nobody could login (/bin/login?), and most of the useful commands had gone, everything else seemed normal. Of course, some things can't stand life without say /etc/termcap, or /dev/kmem, or /etc/utmp, but by and large it all hangs together.
I shall leave you with this question: if you were placed in the same situation, and had the presence of mind that always comes with hindsight, could you have got out of it in a simpler or easier way?
Re: I hope
I had to recover an AD site once, it had only one PDC, no BDC's, but luckily there was a recent backup made of the PDC (Server2k3 and NTBackup).
Process was to reinstall Server2k3 on a clean server, run ntbackup to restore the AD backup, and we were back in business again. Only niggle was hoping that Windows Activation would go through as I was not in the mood to faff around with that - but it went through just fine. I then set up a BDC just in case, but still continue to make backups from the PDC juuuust in case.
And recovering the forest is no biggie as there's about 60 users - but a backup and BDC makes things so much easier.
But yes, forest recovery, especially with multiple sites and domains need to be addressed. Setting it all up from scratch by hand leads to errors and mistakes if due care is not taken.
Re: Oh, shit...
It really is a load of bollocks, if you want to play something small (like pixel dungeon) you have to wade through thousands of similar crapware before finding the one you want. And risk getting a trojan/worm along the way.
I have my favourites - oceanhorn, two pixel dungeon variants (damn that permadeath) and three or so other RPG games. And Marvin (Speccy emulator) in case I am stuck in a boredroom meeting which went past its sell-by time and is dragged out by some self-righteous pompous troubadour, then I can just keep myself busy for a while until said pompous troubadour finishes said boring performance and we can escape.
At the core of it, serverless means that those building applications no longer have to care about how their applications do what they do, they just have to tell the applications what to do. That’s revolutionary. And it opens up really complex application development to people who never could have done this before.
One great example of the power of serverless is Bulk Data Computational Analysis (BDCA). I can take a windows admin who can barely write batch files – they don't even have to know how to use PowerShell – and inside of a day, I could have them writing voice recognition apps. Our hypothetical novice developer can slap a fully functional voice recognition app using little more than code snippets from Stack Exchange and some public sample code from Amazon.
And that is the problem right there. A good coder will be able to recognize a problem (eg exploit or an embedded rm -rf / *) code within the copypasta - but the above windows admin will not know how to spot an exploit or the such, and will compile a big problem...
Keep in mind, ne'er-do-wells will think outside the box - and they will try to obfuscate their ne-er-do-well piece of sh*te code in such a way that it will looks as if it does X but actually does an rm -rf all over the place.