MS-DOS, security theory

[gore]

Heh, damn CHSH, it was a theory of mine because it seemed like it would work. The single tasking part of it still remains to an extent, as all you'd have t do is launch a program, which you could probably code yourself, that would not allow any other threads, or shells, to be spawned from it. There is a way to make DOS more secure, it's like using Slackware, simplicity generally will lead to security, because the less you have running around, the less chance you have of being run over.

For example, why use Anti Virus when it's all you have? You leave room open on the box tro be exploited because more code is in RAM. Besides, to get past usual AV companies, all you need is a Hex editor (May no longer work but like 2 years ago, corporate AV companies would look for names of programs inside the code, not the actual virii string itself, so changing "Nuke" to "puppy" with a Hex editor and saving it, you could defeat the AV).

Chsh, you're a coder, and you seem to have an understanding of how DOS works, so I'll play with your ego

Do you think you have the skill that you could make a program in DOS that would take advantage of the single user single tasking capabilities and make it so no one could exploit it to an extent?

I mean there has to be a way. somehow by making sure that one program is using all resources for you instead of letting threads and shells being spawned as you quite rightly pointed out. Which is something I have learned from reading this thread. Have to remember, when DOS was out, I was a baby, but I still have used it, so either way you look at this thread, at least I learned something.

But now, could a program be written that would allow the advantages of single user/tasking to be shows better?

[less]

i Think u r correct......

I would like to give example of windows NT,
as it got drawback that u have to be administrator to be able to get shell remotely on NT server,

But this drawback has given it great security advantage
that the attaker can't easily attack NT remotely,
as he has to get administrator passward to able to get remote shell on NT.

But it has its costs as maintanance has to be done locally

[Maestr0]

"simplicity generally will lead to security" Yes, its true, complexity is one of the main- if not THE main source of defects in software, however...

"I mean there has to be a way. somehow by making sure that one program is using all resources for you instead of letting threads and shells being spawned as you quite rightly pointed out."

First of they would be processes becauses DOS is not a multi-threaded OS (Basically it has one thread), but aside from that, your one process (I'm assuming this process accepts some form of user input from somewhere since we hope that it does something) would be the process the attacker would seek to exploit, once exploited the attacker will have full privileges and will be free to spawn shells or install TSR (Terminate and Stay Resident) backdoors as he sees fit, god only knows what such an attacker might want with an 0wned MS-DOS box...
Instead of cutting out the advantages(which there are many) of having a multi-threaded, multi-user operating system, how about not running processes (services/daemons) you dont need as in our 'One Process' scenario above, and have the added security of being able to limit our processes' rights and access to other system/network resources?


-Maestr0

[Negative]

Just some things for you to play with, gore:

"Multi-user" capabilities of DOS

C:>command
Microsoft(R) Windows DOS
(C)Copyright Microsoft Corp 1990-2001.

There, you've just created a second shell. The interesting thing is that the "settings" from this second shell are global: the first shell is affected by the changes you make in this second shell.

In the second shell:

C:>set dircmd=/w
C:>exit

Here we set the dir-command to "wide" display in the second shell. If you do a dir in the second shell, you'll notice that dir indeed has been set to wide.
In the second line, we exit the second shell.
If you then do a dir in the first shell, you'll notice that the changes still apply.

The opposite isn't true: changes made in the first shell, don't apply to the second.

You can (afaik) make as many virtual shells as you want (until you're out of memory)...


As the_Jinx already mentioned, TSR might be something to look into as well.
If I'm correct, MS never gave out much details on how TSR works (the DOS command PRINT is a nice example of a built-in TSR), but it didn't take long until the masses figured it all out.

Here's (basically) how it works:
-Normal situation:
- program is loaded into RAM (640K for system, some for DOS, rest for programs)
- user does what he has to do
- user ends program
- program tells DOS "you may now terminate me"
- DOS forgets about the program
- as soon as another program needs to be loaded, DOS overwrites the last program with the new one
- end of story

-TSR:
- program is loaded into RAM
- user does what he has to do
- user ends program
- program tells DOS "you may now terminate BUT DO NOT OVERWRITE ME! I'M GOING TO NEED x KB OF RAM"
- DOS forgets about the program
- as soon as another program needs to be loaded, DOS loads the new program AFTER the TSR-program

Interesting stuff: the TSR chooses how much RAM it wants, and DOS obeys.

[Tiger Shark]

Gals and Boys:

Just a little note......

Open a cmd prompt on your shiney new WinXP box and type attrib *.*

Whohooo.... output!!!!!! Attrib is alive and well and living in your windows box everywhere.

On the point of DOS being secure:

You need to consider the type of security you are referring to, (remote or local). Then you need to decide whether we are talking about basic install or "enhanced".

A basic install of DOS is secure from all remote attacks since DOS itself contains no built-in remote connectivity. However, a basic install of DOS, (assuming no BIOS password has been set), drops any user that has booted the box to the effective power of root.

An enhanced install of DOS, (let's use one where Novell was placed on top of the OS), is potentially vulnerable to remote compromise but in some circumstances could be made more secure in that it would require a network login before access was granted to the system itself, (IIRC). Of course, that was far from unbeatable but it would keep your average (L)user off the box. There is also the point that even though network accessibility was enabled it tended to be outbound only, (ie: no services were running), and as such it remained less exploitable than the more "advanced" systems of today.

While the idea is fine Gore, it does lack some practicality.... It's true that the simplicity of DOS is a benefit, the unfortunate thing was that it's simplicity was not accompanied by any access control. Damn, it could have been quite nice had there been access controls built in. You also need to recall that this product was out there in the hayday of mainframes. That was where the secure corporate computing was being done at the time. PC's were just wordprocessors and spreadsheet "things". Major computing wasn't done on them, that was left the powerful number crunchers.... Ahhhh.... IBM 370's, the "wonder" of JES.... Sorry, memories.... I still have my JES "bible" somewhere, deep in a box....

[gore]

This is post number 2,000 from me. Heh, I made it!


Anyway,

Thanks to everyone who took part in this. And thanks to Chsh, Pooh, Negative, and Meastro, and Tiger, for taking the time to point out flaws in this theory.

Now, from what I'm learning in this thread, you could in some way rewrite a part, or parts of, DOS, to actually begin to take conformity to my theory. Remember, I'm not a coder in any way, well yet, I did get my first Perl thing to work last night, which isn't bad considering I just started learning it last night...Well teaching myself, but anyway, I still think there is some way to make my theory fact if you rewrote parts to DOS, and made a program that would not allow remote connections, or shells to be spawned from anywhere but the keyboard. Or something to this extent.



Add a BIOS password, and you have a box that needs to be logged into from a physical perspective. If there was a way to password protect every part of the system, which I'm sure there is, this may add to the idea. But then again it would also add to complexity, and start to take away from the simplicity I'm going at.


Would anyone argue that, with a re-write, this theory could possibly be proven? Or at least have some fact to it?

[Tedob1]

id like to point out that although ms is no longer involved in dos its still being developed. caldera dos is now open source but the biggest push is freedos

http://www.freedos.org/freedos/

you can downlaod an iso and install from a cd

[AngelicKnight]

Hmm...well to test the theory, why don't you (or someone) do what one of the other AOers did recently (I don't recall who it was off-hand at the moment), and have a hack-this-box contest where the target is a spare box you've set up with DOS. Record the results. Report back here. Could it be, Angelic just had a useful idea?

[Tiger Shark]

Angelic:

My DOS 6.0 disks failed to work long ago..... It would be funny though.... Leave an internet connected DOS box open to the world and see what a simple NMap scan comes up with as an OS guess.....

Then Snort the box and see if anyone even tries...... <LOL>

[gore]

Ohh! That's an idea!

If I can get an older machine, or someone here get's one, put DOS on, and let it online.

I'd do it now but the only boxes I have are new, and DOS runs good on them, but the NICs and so on obviously don't work.