Mainly the fact that antivirus writers as well as system coders will work on it to make the virus unable to harm, when they have the docs

SPTH, you know how an AV works in the "pattern" way, for sure. It's like for biological viruses. You have a database with all known viruses samples in, and if you want to know if something is a virus, you see if it matches or not.

Well, take care nobody could "open" the database and let those valuable specimen go. I mean, for the informatics way, the loss of data is nothing. However, the contamination phenomenon ...

Interesting how this thread diverged, but I think the new subject is quite important.

I think what SPTH brought to light was fairly important. I think it would be more beneficial to talk about ways of improving the security for MenuetOS rather than writing viruses for it though.

For CRC and Blue Owl, two important things, Menuet is currently in design phase so we can do with it whatever we want and secondly it is made in assembler, not C. I will clarify later why I make these two points.

For CRC, it is true that it is impossible to execute a data segment and code segments are not writeable. This has two qualifications though. You must be in protected mode, and the data segments and code segments don't overlap. If the data segments and the code segments overlap then of course you can run code at the memory located at the data segment, but you will need to use the code segment to run it.

You are semi-correct, 8086 was not designed to be secure. However, 80386 and up are very secure. But guess what, you have to use the security stuff they have designed in order for it to be secure.

For Blue Owl, thousands of lines of code is not really that big. But won't argue with you on that point, just my opinion. I will also restate my other point again, in normal OS operation, there should be no need to overwrite application files unless you are doing a patch. It wouldn't make sense for a person to download a game called "pong" and then the first thing it does is ask permission "OK to overwrite win.com".

I think the confusion here is what current OS allow right now. Just because current OS's allow you to overwrite EXE's doesn't mean it is a necessary part of daily activities and that it couldn't be prevented with security restrictions. Same thing with executing code in data segments and overriding security permissions. An OS doesn't have to allow this. That thing about overriding the security permissions, well duh. OS security really doesn't work if an application can call a function that is named "Turn_off_OS_security".

The other thing is Menuet is made in assembler so it doesn't have the restrictions of C. I never realized it before, but probably the reason why we have these security leaks is because the OS's were made in C. They don't accomodate for the CPU's individual security architecture. I think it also might have something to do with the way data is passed in functions. Any pointers are just that: usually a 32-bit pointer. This would mean the program being called would need to have access to the same segment as the calling program, thereby one universal data segment. Of course security then goes out the window. Same thing for code segments.

So the point being, we are not forced to implement the weaknesses of the other OS's in Menuet both because it is in design phase and is written in assembler(so it doesn't have to conform to a specific way of doing things).

Menuet might actually use a universal data segment, so maybe I was mistaken, still don't know. The other pain about security is that it is more complex and does slow things down a bit, but worth it in the long run. Menuet is already using paging and task switching, so obviously speed isn't the biggest concern. The flat model with software task switching is definitely the fastest and easiest model, but offers no real security.

I think SPTH's last points are excellent. I also kind of figured that was what was happening with your web page. I don't think too many would dissassemble hundreds of thousands of lines of source code to find out if there is a virus in there or not. And it is easy to be pretty sure there are no viruses in code right now because the community is so small. Once more web sites start popping up with Menuet programs to download though, viruses could easily be put on these web sites without anybody noticing.

...Gomer73

[quote="SPTH"]GOMER73:
PS: To SPTH, why do you have viruses embedded in your home page? McAffee gives me a virus warning when I visit your site. Is this intentional and if so why?
---
There is no virus, McAfee just detects my handle (SPTH - long verison)

................

I want to review my thougths.
There is a virus for MenuetOS, and there is no kind of security for it!
Sure, for now, MenuetOS clan is very short, and this virus won't spread very wide for that reason.
Anyway: As in 2-4 month there will be the source open of the virus with description and an article about viruses for MenuetOS, there may be more viruses for that OS.
Now you (the main coder Mike and even all other coders) have to deside if you want to be scared everytime you open a new app (and even you would look at all sources - at long ones you could miss something) and if menuet will ever grow up to a more widespread OS, other users (with maybe no asm-knowlegde) will be scared of it.

And there could be other things, like cross infectors (windows/menuet), which will spread very well (because of windows), and if they find one, they could infect menuet-apps (and i'm sure that nobody disassembles every menuet-file before running) - that way also you could become a victim.

greets, ...[/quote]


Let's see here " homepage fires off an alert"

and here is a "to do" list.

Guys, where is the help coming from here.

We have to wait 2 -4 MONTHS for docs which already exist ?

When we get something helpful out of this thread I'll truly be impressed.

Ok, I agree. I guess it is tough finding a balance between small,speedy,non-secure and larger,slower,secure. Anyway the problem is, that something like an operating system can never be 100% secure, there is always a way. For example, all this security would not do anything against source code virusses. I think with SPTH's virus we have invoked a discussion about MenuetOSs security, and that it is precisely what it was made for.

Funny to think that the original post was only about a bug in Menuet.

I'm trying not to make this post any longer, but I need some info.

Since there are some virus writers here, I might as well use their knowledge.

For BlueOwl, for my system(the setup I will give in a moment) how would it be possible for a source code virus to penetrate?

My system setup is that only installed applications can be run. You can't just run a file. The process that runs the install app routine would ask you for a password before continuing, so no process could do it in the background invisibly.

All permissions are assigned during the install process, by default programs would be given read file(not OS files though) and write file access(to their data directory or a document directory). Disk and read and write access would not be given to any app(this would be another password protected thing). Processes can read their code, but not write(doesn't make much difference on a security level though). They can allocate new memory and deallocat their segments, but not touch or even know about the segments of other processes(unless the process gives them permission). All apps run at ring 3. The LDT only contains the current program's segments. When a task switch occurs, the LDT only contains the next program's segments. All I/O routines are accessed by call gates(which means the OS limits to which code you can call to) in ring 1, with call gates it uses a diferent stack so you can't execute any code the os doesn't want you to. Memory allocation and task switch are done in ring 0.

With this scenario, I don't see how even a source code virus could do any damage to the system. At install the user would decide what access the application needs. I agree that if you are installing I/O access applications then a source code virus could penetrate the system, but the user would be made aware of this and have to apporve it so it is unlikely that it would be done accidentally. Also, I can't see many programs that I would download that need this access(except for drivers like video drivers, etc.).

Obvious this system(as any OS is) is vulnerable to any boot sector viruses. But the virus would have to get on the boot sector before the OS is run, so I don't see this being very likely.

If any virus writers out there can tell me how this OS could be penetrated, please let me know, it would be greatly appreciated. In my view I think it is impossible for a virus to do any damage to this OS(trojan or otherwise). Of course I am talking about file viruses, e-mail and document viruses would are a different matter(but similar thought could be put in the design of their scripting as well).

In case the virus writers are C programmers, here are some terms:
Ring 0 - at this privilege level anything can be done
Ring 1 - for this OS, I/O access can be done, but the LDT can't be changed
Ring 3 - for this OS, the LDT can't be changed, can't access I/O. This is where most programs would be run at.
LDT - Local descriptor table, in this context a table that holds all the segments for the current process. Can only be modified at Ring 0. Data outside the segments listed can not be modified or accessed. Each segment has a privilege level and Ring 3 code cannot access Ring 0 or Ring 1 data.
Call Gate - Allows you to call a function at a higher privilege level. It is located in the LDT, so can't be modified other than at Ring 0. Points to a specific routine, so you can't jump to another location within the function. Can only be called, not jumped to, so you can't modify the return address. Also uses a higher privilege level stack.

Please let me know of any security weaknesses you see.

Thanks,

...Gomer73

PS: Sorry to prolong this post, but I think this information could be useful if Menuet would implement it.

PC BIOS Setup, isn't there such an option to prevent any virus write MBR?

The feature is no longer valid, since you no longer have to hack into the boot record, just hacking the bootloader (NTLDR,grub,...) would be enough.

Most systems, including MenuetOS, allow you to modify the boot records easily. (It's even more easy in windowsNT/XP than in windows9x)

Groenten,
Tolle_w

For a source code virus to penetrate, it woul dhave to be able to infect source code files. If you had downloaded an infected compiler or other source code modificator, the source code virus would start infecting your projects. If you share the programs you make with other software producers who make compilers, soon lots of peoples disks could get infected. The only problem would be that the virus could only spread thru the source codes of compilers, but infected apps could still do something on your computer.

Anyway, i think it is almost impossible to keep all files (documents, data files etc) of all applications seperate, as I am sure you want to edit some file with 2 seperate programs at some time (grapical files for example), so when this occurs the virus could possibly jump from one app to another. But anyway, there are probably other options (maybe in some strange exploit, or whatever) that could make it possible for a virus to survive.



If you would prohibit programs from running uninstalled, and made sure programs could not access each others data, i think e-mail and documents virusses would also be a lot more restrained.

However, I think the OS you are scetching, would already be a much better security system than most people use nowadays.

bloglite:
"We have to wait 2 -4 MONTHS for docs which already exist ?"
Well, the executeable file is already at my homepage in a zip-archiv! you could download it, unzip and disassemble it with a diassemble-tool! I'm sure that would take some hours, but if you can't wait for the next issue of our magazine, it's possible! anything you need is time, asm-knowlegde and Menuet knowlegde!

16.07.2004: I added some links to AV reports of my viruses and changed some links. Currently I'm working on a real new Menuet-virus, which will be good i think ;-)! About rRlf-page: It's not updated for more than two month, but don't worry: Philie is still alive, he's just damn busy!

29.06.2004: Finally, today I finished my latest article: MenuetOS infection. As it's a very long and detailt article, I'm very proud that I could show it to you soon. This article will also be released in rRlf#5. Another thing: KAV released a new update, and in it a virus called 'Menuet.Xymo.a'. I really hope that you will write a report about it. :-) My next project is, of course find some other secrets in that OS. That means: much work again.

24.06.2004: Again today: As I thought that I should release the executeable of my new virus, I did it (in 'project'-subsite)... Source will follow in rRlf#5!

24.06.2004: A big news: I finished my MenuetOS virus, which is the world's very first one, and it's called Menuet.Oxymoron. I sent the executeable to some AV-reasearchers, and the source will be released in rRlf#5. Now I start to write an article about MenuetOS viruses. News about that will come soon...



Just some more of the same I gleaned from Web search for our "hobbiests" activities. Looks like a combined effort to me.

to SPTH:

if MenuetOS runs on Reiser4 or JFS (NOT fat32/16/12/ntfs) and slightly change interface of the kernel for fs, then still the virus gonna works?

--
I don't really understand why MenuetOS have to use MS'property(fat12/16/32/ntfs).

fasm9: 1) A new fs will not change anything, and changing the interface will likely just make it incompatible with all current apps, including virii, which, including virii, will need to be modified to accomidate for the new interface. unless any security is added to the interface, it wont make a difference. just changing the fs will not do anything, get over it!
2) what would be a better fs for a small floppy based OS? fat12 is simple and readible on anything. it is a real pain to work with ext2 floppies on a windows machine, but you can mess with fat12 floppies very easily on FreeBSD, Windows, Linux, or even my old 68k Mac very easily (and don't say that's useless -- suppose you have a mac and an old HD-less PC and wanna play with Menuet -- you can edit asm files on your mac and compile in Menuet).

now i know why it isn't!

Because actually, nobody don't know how to implement fs with Reiser4 or JFS in MenuetOS, also, it haven't been happened to any other small-oses.

These fs is not written in asm, and it need deep understanding C, OS, hardware, algorithms, etc.

If changing fs is not enough, why MenuetOS doesn't mimic Linux security model? of course this also require reinvent wheel in FASM..

MS' security model thumb down.

To have more filesystems, you would want a VFS layer (like Linux, FreeBSD, pro'lly Windows NT & most other big OSs have) which uses one interface to access all the filesystems available on the machine. Google it for more info.
I am actually working on a VFS layer for MenuetOS, but the way I am implementing it will need apps to be able to be filesystem "drivers". it is not meant as a VFS layer for MenuetOS, but rather so that MenuetOS kernel can be used in my OS before I write my own kernel.

Another argument is that these filesystems are HUGE! a Linux kernel with XFS support will not fit in a floppy! This will pro'lly be smaller if written in asm, but support for a few better FSs would be near useless and could double the size of the kernel!

I suspect the reason nobody has implemented a superior filesystem is, not that nobody has the ability or could be bothered doing it (MenuetOS kernel coders have written the rest of the kernel!), but because there is no point! FAT12/16/32 can be used by near any computer, it's implementation is small, and it has little to nothing to do with virii!

If you want to implement another filesystem for no apparent reason, go for it. it's your time ur gonna be wasting.

I myself would like to see a better filesystem, but it isnt the first thing on the agenda - maybe a loppy driver would be a good idea first. Right now MenuetOS doesnt need a dedicated partition on HD that only Linux and other big open source OSs can use. The most important issue right now is that other OSs can access it. Also FAT is there (i assume) because earlier in the development of MenuetOS it was the simplest one to implement and was chosen because of that.

"If changing fs is not enough, why MenuetOS doesn't mimic Linux security model? of course this also require reinvent wheel in FASM.." - if you are refering to different user accounts and such, that would be good, but again - not first on the agenda.

I really think it is important to make MenuetOS-Linux relationship.

Everything in FASM, in FAT12/16/32/NTFS, in 1.44 FLOPPY is OK.

But sooner or later, if you want something more reliable than hobby, then you will need HDD, something what Linux had done(very long time).

--
FAT12/16/32/NTFS is MS' property,
it's dangerous enough when MenuetOS come with successful, mature.

Yay, let's move towards Linux, big & buggy yet still better than windows.
I don't think MenuetOS should move towards any other OS. It is MenuetOS, not Linux in asm. I think it is certainly too Windows-ish and needs nice things like a VFS layer andlogins, but I think, for now at least, FAT12 is the best option.
Linux has a lot of abstraction (but still not enough imo), and to add such things to MenuetOS, it may as well be a completely different OS, as MenuetOS's ABI offers little to no abstraction - in a Unixy world,
reading text from the user would be no different from reading text from a file, and this sorta stuff is very different to what MenuetOS does. If you want a Linux-y OS in asm, write one (i think that would be really awesome - Linux kernel in asm).

If you want something done good, do it yourself!

Well, if i have such a great ability, why i have to be here?

and no! the direction is wrong

Linux -> MenuetOS (X)
MenuetOS -> Linux (O)

Because, many things in linux are mature, but linux still need desktop area like MenuetOS!

The common factor between MenuetOS and Linux is FASM. when FASM have such an capability like abstraction/oop/c-compiler than merely assembler, Then not so difficult to make relationship between them, it's up to future-FASM.

FASM is an assembler. It compiles code written in assembly, _not_ any other language. There would be no point turning it into a C compiler as there is a far better one known as GCC!
I was in no way suggesting "porting" the Linux kernel onto the MenuetOS kernel, but I was rather refering to providing the Linux ABI to MenuetOS or writing another kernel that is compatible with Linux but written in assembler.


Linux is written primarily in C, and the parts written in assembler are in GAS, which is very different to the syntax used by FASM.

We are here because Fasm is merely an assembler and fortunately it will keep as it is.

I see FASM not only as a language but also whole independent system.

so why not merely c-compiler/oop/abstraction 'in asm'?

why people prejudge with see the already-maden?

my view of Today status:
asm- (cut by cs-guy(acm,ieee)/industry) -c-compiler

and my view of Tomorrow status:
(everything:c,os,linker,debugger..) 'in FASM'