Re: Minor note
The "rule" usually cited in this context is that quotes gravitate to the more distinguished culprit. How sad for poor old LBJ. :)
Ah, the sweet, sweet smell of Monday. What better way to start your week than combining it with the latest confession of wrongdoing from The Register readership in the form of our weekly Who, Me? column. Today's blast from the past comes from a somewhat unrepentant reader we shall refer to as "Charles". Take yourself back to …
The "rule" usually cited in this context is that quotes gravitate to the more distinguished culprit.
If you really want people to take your comment seriously, tell them Winston Churchill said it first.
-- Benjamin Franklin
How sad for poor old LBJ. :)
I'd prefer to think "good on ol' Sir Pterry; he's risen to the ranks of quotation magnets" (among whom Churchill, Franklin, Mark Twain, and Oscar Wilde are prominent), but I do see your point.
I agree totally.
And I've also managed to bring a few mainframes and minis to their knees over the years.
The classic, related here before, was on a DEC VMS Admin course in Reading. I was bored, the course was covering stuff I already knew, so, for a laugh, I did show users and started logging people off our VAX (each course had their own VAX). It worked fine, so I knocked up a quick bit of DCL that exported the user list to a file and went through the file and logged everybody but big_D off...
Worked a treat. So I went one step further, I turned it into a self-submitting batch file. Submitted it and sat back and relaxed and looked around at frustrated faces as people kept getting logged off...
Only I then made the fatal mistake of logging off myself. That was when I found the fatal flaw in my logic. During the login process, you don't have a username, but you do appear in the "show users" list as <login> and a process ID. ZAP! The login process just wasn't quick enough to get me from <login> to big_D before the batch job had killed my process.
Luckily the instructor saw the funny side, even when he couldn't log onto the console in the computer room. In the end, we had to do a hard reset.
:Loop; type Alt+256>a.txt; type Alt+256>b.txt; Type a.txt>b.txt; type b.txt>a.txt; goto loop.
The faster the CPU, the more RAM it has to play with, & the larger the drives it starts on, the greater the "fun" that results.
You'll need a boot CD/USB device handy so you can delete the two text files to regain control over your computer.
Kiss all the free CPU cycles & drive space goodbye.
The fun you can have when someone challenges you to crash their system without triggering the anti virus routines.
*Ominous maniacal laughter*
Test in Windows command prompt :
Type a>a.txt <ctrl>
The system cannot find the file specified.
So, unless you've already created file a.txt and b.txt, your script is going to fail to do much more than use CPU cycles and fill the command prompt buffer.
And, as soon as you kill the window, the problem is gone.
Do you *really* think I'd post actual code that could be copied & pasted into a CLI that would run?
I just wanted to get the concept across. Those that want to make it function will know how, those that don't will either RTFM to learn or will get nowhere.
Sorry for the confusion.
In the days of spinning rust, perhaps. In the days of solid state storage, urandom is a good compromise between tricking the disk write routines (i.e. ensuring blocks are erased instead of marked for garbage collection) and having to constantly buy and dispose of destroyed media.
If anything's going to cross security domains, physical destruction is important of course. If it's just being wiped for reuse at the same security level, and the recipient isn't authorized to access the stored data, urandom does a pretty good job of wiping things out.
He worked for a government lab while also getting his PHD in particle physics, and during some downtime created some code which generated a recursive zip file, and not just a straight one directory, recursion etc. no it had 4 directors at the top level, which looped back at various points after various other named directories. He then wanted to run the code through his code analyser at work at the government lab, where his major coding tools were (he worked on a major project involving creating software for new research models) so, as you do, he emailed it to his work address (because they don't like taking media and plugging it in, that way lies espionage, and virii and such.
And now you've probably guessed what happened....
So I'm assuming here that he sent a sample of the recursive zip file to his email address and the virus scanner picked it up and...
What happens next is the interesting bit. Any competent virus scanner would (hopefully) be able to detect a malformed zip file and not try and parse it for eternity, and then remove it from the email. I'm guessing this is not what happened, which strongly implies that the bit of software designed to explicitly look for malicious code is pretty poor at finding it.
The severity of the result is going to depend on whether this is a single instance 'scanning' all email, or a separate thread for each email, and whether it has been designed with any sensible timeout. On balance, I think I'd probably design such a thing to use a thread pool, and scan each email on an idle thread, queueing them up if the thread limit is exceeded, and putting a sensible timeout on the processing (maybe 60 seconds which should be more than ample for most cases), with the timeout configurable. There may still be some other attack vectors to cause a denial of service, for instance flooding with multiple malformed messages, so perhaps limit the processing to one message per sender simultaneously. That's not going to deal with multiple malicious emails fro multiple senders, but that's the sort of thing that's getting into DoS prevention/mitigation territory and it has its own solutions.
There used to be quite a few virus scanners that would try to open any zip file they came across. Cat /dev/zero | gzip > nasty.zip was a quick way to create the magic expanding zip file, which when the simple-minded virus scanner found it would crash the system after eating all of its memory.
In a similar sort of theme, the senior staff of a certain Yorkshire university discovered that they had a problem with pornography being emailed around the place, and insisted upon punishment for anyone receiving such filth by email.
Inside of oh, about five minutes, the entirety of the senior faculty were magically receiving both barrels of "rule 34" pornography; indescribable stuff that presumably someone somewhere likes, but which otherwise triggers gag and vomit reflexes whilst at the same time violating anti-porn rules in quite a staggering number of ways.
The rule was rescinded remarkably quickly, with quite a few senior academics forswearing off computers for life.
At one place where I used to work, I can remember someone being hauled over the coals for receiving a dodgy email of some description. In true Kafka-esque style, TPTB would neither tell the individual involved who had sent it, nor what it contained, but were determined to punish him for it anyway.
Needless to say, that particular company no longer trades.
When you say that a competent virus scanner should be able to detect a malformed zip file, I think you may be missing the point. I understood the zip file to be well formed. It's certainly possible to make a zip quine, and although I've never personally seen it done it should in principle be "straightforward" to extend the technique to a valid zip file which contains multiple copies of itself with different names.
Yes. There are various sorts of well-formed pathological zip files (and similarly for other archive formats), well-documented in forums such as BUGTRAQ and VULN-DEV. The topic may have come up in an article in PoC||GTFO, too; I have a vague memory of that.
Anyway, this is why modern malware scanners generally have configurable limits on directory depth, expansion factor, and nesting for archives and other compound file formats. If a limit is reached, the scanner treats the file as malicious.
Of course this is an arms war, with attackers finding new looping constructs the scanner developers forgot to limit, creating polyglot files that scanners interpret incorrectly (or at least not in the way that end users interpret them), and so forth.
"including a small program emulating a login screen, that dumped the entered username and password in a file."
I did exactly the same with old novell dos logon. Whilst they taught you useful things in C or Pascal class , they never seemed to bother with the finishing touches - like compiling and packaging your program. So i had to leave my my malware running in the IDE thingy.
Got found out too, Still got the written warning . very proud of it .
... such shenanigans were considered part of the coursework, if unofficially.
These days, it'll get you expelled and put on a terrorism watch list.
Back in the day, the computer revolution happened. These days, companies like Apple patent paper bags and rounded corners, and charge $999 for simple, nondescript monitor stands. Coincidence? You decide.
and charge $999 for simple, nondescript monitor stands.
<sad Apple geek>
How dare you call it simple and nondescript! Shhh, she's going to hear you!
</sad Apple geek>
Anyhow, I really wonder as to why did people give a hoot about this. It's basic capitalism. Sheep willing to pay, and a company willing to sell to the flock. Supposed customers of "Pro" products are willing to splurge $6K - $15K on a display, ahem, reference display, so why not sell a $1K stand if there are customers willing to pay?
customers willing to piss away tax payers money that should be being spent on nurses , medicine & bandages etc , not lining your office with all the finery you can waste money on just because you think as the head of finance you deserve more expensive equipment than anyone else
Exactly!
One point though:
Separating actual fools from their money is unethical.
Correct, but crooks have been separating fools from their money since forever. This is nothing, erm, "newsworthy". Or have people believed up until that point that Apple was a charity (or an honest garage-run neighborhood sale), not a big, fat megacorp?
No. Back in the day spotting how to do that was almost required, doing it by accident forgiven, finding out how to subvert the system to do it when you shouldn't rewarded with beer and actually doing it on purpose cause for a severe spanking.
But I went to a university whose admin understood undergrads.
he'd be called a script kiddie, and punished accordingly. Which he deserves, from an ethical point of view.
That aside, if I were to be responsible for hiring for any organization which does "serious" work (i.e. security contractor, banking firm, TLA), I definitely won't hire him. Though he's a "deviant soul", thinking out of the box, and creative (mischievously so), this non-conformity could be a curse as well as a blessing.
If you ever find yourself having to unpick such a thing in Windows - 7Zip's file explorer will let you rename files that Windows won't.
You can usually also do tricks with drive mapping to make windows think the filepath is shorter, but that won't work if every individual folder name is already at the limit.
Oh, that is old. With an easy fix.
md empty
robocopy empty directory-to-kill /s /e /r:0 /w:0 /purge
rd empty
This method even gets the link-looped directories, for example, in the user profile.
If you want to make it better set obscure rights after creation, and remove all inheritance ;). Easy to solve for those with enough experience, but hard for those who never had to struggle such weirdness before.