Sophos U-turns on lack of .bat file blocking after El Reg intervenes Sophos' WS1000 web appliance not only fails to include batch files in its download file type block list, but said it would only include the ability to block them as a feature. WS1000 is an enterprise-targeted secure appliance and intends to protect "every user, on every device, everywhere they go" by prohibiting particular end …
Block them all!
It's the only way to be sure.
Seriously, I worked for a company that filtered out all attachments (except for .TXT files). Some of the security team even argued against that. Why?
Imagine a malicious text file containing malicious command lines. It could be mailed, downloaded, extension renamed to .cmd or .bat and then PRESTO you have mail-borne malware at your service, albeit very old school style. You'd still need a socially engineered dummy on the end of the phone to deliver the payload but they are pretty easy to find.
If you can convince the recipient through text in the body or subject line of the email, then malicious instructions can probably be delivered directly to the recipient's brain using an old-fashioned phone line, or even in-person contact; the only way to be secure, then, is to quietly disconnect keyboard, mouse, and other potential brain-to-computer malicious code transfer vectors from the recipient's machine, and hope no-one notices.
"Like all Un*x variants OSX has an Executable bit in the permissions for a file"
Two bits of pedantry for you.
1. The executable bit is a property of the file system type, not the operating system.
2. NTFS has one, too.(1)
(1) I didn't know this either, until I did something unusual with Cygwin and ended up with a .EXE that could not be executed because it didn't have the Executable permission...
The executable bit is a property of the file system type, not the operating system.
Yes, though the standard set of filesystem access permissions is standardized by SUSv3 (and has been part of that line of standards since POSIX).
NTFS has one, too
No, it doesn't. NTFS has ACLs, and Cygwin uses them to emulate POSIX permissions.
"No, it doesn't. NTFS has ACLs, and Cygwin uses them to emulate POSIX permissions."
Well, when you look at the permissions on an ACL, there is one marked something along the lines of "executable". (On my system, whatever it actually says has been replaced by a French word ...)
Are they actually saying that you can't add your own custom extensions and rules, you have to wait for a feature to be upvoted and added?
That's a dynamic way to operate in today's security landscape where zero-days are abundant. Reminds me of the good old days where you could opt for quarterly or monthly AV updates to be sent out on disk.
FIRST hit on Google
50 potentially dangerous file extensions on windows
Yes, it's got bat pif scr cmd etc.
I deleted it
You jest, but I'm sure more than one person here has seen someone do that.
Back in the day, when disk space was scarce, a fellow developer was cleaning up an AOS1 machine, trying to free up some space. He spotted /bin/[, thought "that must be some crap that got created accidentally", and deleted it.
Of course /bin/[ is a (hard) link to /bin/test, and is used to implement the "[ -whatever ...]" syntax in the Bourne shell, which does not have it as a built-in. (This the the real Bourne I'm talking about, not one of your "we call it /bin/sh but it's just a link to bash or some other monstrosity" shells.) And it is used by many a shell script in the AOS / BSD 4.x /etc/rc sequence.
Took a while to get his machine booting again.
1IBM's port of BSD 4.x to the PC RT and the "Crossbow", a never-released RT-on-a-card for the PS/2.
It's a long time (15 years or so) since I used Windows, but I seem to remember that the system did NOT use the file extension to work out how to execute an executable. I think if you had a binary executable something.exe and renamed it to something.bat it would still work. Or is dementia kicking in?
That's the reverse of what he said. I suspect renaming an executable .bat and running it will work, because the check for any file will look like:
'Is this a PE/COFF file? great, I'll run it!'
or
'Oh it's not? Well what program do I have associated with *.bat, oh it's cmd.exe, great, I'll run 'cmd.exe foo.bat'.
This is broadly similar to how Unix does it, except the association is the #! line at the top of the script rather than being a central registry elsewhere in the OS.
Well that doesn't seem like a good idea. I'm sure it's possible to delicately craft a file which could be interpreted either as an binary executable or as a text batch file. If you just rely on the executable bit, how do you know which interpretation to make.
I use them after any code change to get change from source control then fire off msbuild clean, build and package operations (ms tools for compiling code and then packaging it) followed by the bat file launching scripts (powershell, supporting more complex doze scripting than .bat files do) to then deploy on the test environment and run tests.
Realised that sounded scarily DevOps - but (automated build & deploy & test) it the sort of thing that has been done for ages, in many companies,well before DevOps became a buzzword.
Arguable. A typical definition of "executable", in this case from wikipedia;
In computing, an executable file or executable program, or sometimes simply an executable, causes a computer "to perform indicated tasks according to encoded instructions,"
A script or batch files certainly meets that definition. They may not be compiled binaries, but they do contain a sequence of instructions which gets executed when the script is run. For a compiled language, the executable is the output of the compiler; you can't execute the source code directly. But for an interpreted language, the source code is the executable; that's what you run. It may not be an entirely usual usage of the term, but I think it stands up.
Also: if you set the executable bit on a unix script file it executes just like a command from the POV of the typist.
Which is how you can suborn unix servers by replacing binary stuff in /bin and /sbin with malicious kiddie scripts.
Came across a real world example in a discussion of hacker use cases some years ago. Hard to do if the SAs know even half their job, but who routinely checks the stuff in /bin to see if the content has changed against some baseline?
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
