Index
> MenuetOS > Bug in MenuetOS 0.77Goto page Previous 1, 2, 3, 4, 5 Next |
| Author |
|
|
Gomer73 02 Aug 2004, 18:08
For CRC:
----------------------------------- Since there are currently no viruses. A pattern scanner aint going to do the job until after you have been hit with a virus. Right now the MenuetOS community is so small that if a virus was ever found, it would be deleted from all the web pages where it was found, so it is unlikely you would ever run into it unless you were the first one, and then in that scenario the pattern scanning is useless. And yes, that is what I mean to do, make it so that programs can't directly access the hardware. Kind of like the super user mode in linux. So that apps cannot overwrite other applications unless you have already OK'd them to do that. The disadvantage of pattern scanning is somebody has to be hit with the virus at least once before it can be put in the database. If you had the choice between that or not allowing access to overwrite system files so the virus would do no damage, which would you prefer? ------------------------------------------- As per file systems. I can kind of see FASM9's point even though it wasn't clearly stated. Windows OS's do have a flaw using fat32 in that anybody can write anywhere on a fat32 partition. This is a weakness in the OS, not the file system. This isn't true with NTFS because you can set user rights. However, user rights could still be set on a per file basis with FAT32, it is just that this has to be built into the OS, and not the file system. So it doesn't really matter what file system an OS uses. You can still make each one with the same protection. It just is a difference between where the security system is set up(in the FS or the OS). 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? |
|||
02 Aug 2004, 18:08 |
|
|
crc 02 Aug 2004, 18:57
Quote: Since there are currently no viruses. A pattern scanner aint going to do the job until after you have been hit with a virus. Right now the MenuetOS community is so small that if a virus was ever found, it would be deleted from all the web pages where it was found, so it is unlikely you would ever run into it unless you were the first one, and then in that scenario the pattern scanning is useless. True. But with there are sequences of code that can be considered "dangerous", and the code scanner can watch for these. I think this is called "heurisitics" and is already used to help catch unknown viruses 
Quote: And yes, that is what I mean to do, make it so that programs can't directly access the hardware. Kind of like the super user mode in linux. So that apps cannot overwrite other applications unless you have already OK'd them to do that. It won't necessarily stop viruses; if they are loaded into RAM, they can perform buffer overruns, etc to execute arbitrary code. I *have* done this under Linux and Windows to run 'insecure' code with higher privilige levels. ---- I couldn't find any viruses embedded into SPTH's web site after a careful read over the HTML code for each frame. Maybe it's flagging the JavaScript? |
|||
|
02 Aug 2004, 18:57 |
|
|
Gomer73 02 Aug 2004, 20:18
My scenario would not be vulnerable to buffer overruns. But if you could explain it further, that might help.
If all data is segmented, this won't occur because you hit the limit. And I am guessing it has more to do with program(ring 0) code rather than how the os is setup, though like I say segmentation would help prevent even vulnerabilities in poorly written ring 0 code. Please let me know exactly how you would exploit using this method. I don't know if I ever ran a heuristic scanner that detected an unknown virus. All the viruses it detected had a name, therefore not found by the heuristic method. A theory is nice, but proving it in real life is a totally different matter. SPTH's virus on his html page is identified as Bat.ow/btg by McAffee. |
|||
|
02 Aug 2004, 20:18 |
|
|
BlueOwl 02 Aug 2004, 21:53
If the virus could get per-process resident, it could for example infect when you'd put an exe in an archive, and you would not see any difference.
Programs normally make lots of reads and writes to everything (even exes, when updating) and popups would be popping up every second if you would buffer all. And if you would not buffer it all, it could most probably be exploited again. |
|||
|
02 Aug 2004, 21:53 |
|
|
fasm9 02 Aug 2004, 23:16
> They won't. But that's a totally different scenario. When you have Linux, you don't run Windows/DOS apps on it! There are different viruses for Linux...
yeah different, real protection power is in GPL. |
|||
|
02 Aug 2004, 23:16 |
|
|
Tolle 03 Aug 2004, 05:03
Writing a virus for menuet is like taking candy from a baby, there is simply no security provided in the system. BUT the basics for providing more security are there. Any program currently has the right to freely modify kernel.mnt.
Two cents. Tolle. |
|||
|
03 Aug 2004, 05:03 |
|
|
comrade 03 Aug 2004, 05:20
MenuetOS is an enthusiast operating system, and I do not think such security is a concern.
|
|||
|
03 Aug 2004, 05:20 |
|
|
mega-squall 03 Aug 2004, 09:58
Quote: Programs normally make lots of reads and writes to everything (even exes, when updating) and popups would be popping up every second if you would buffer all. And if you would not buffer it all, it could most probably be exploited again. Use some kind of "firewall" for local acces ? With an interface like zonealarm's ? This is just a suggestion ... Quote: MenuetOS is an enthusiast operating system, and I do not think such security is a concern. ... for now ; but what when it's grown up ? Such security systems take time to be developed. We shall be ready when somebody begin to feel we're taking too much room, or just write something funny to see if works ... |
|||
|
03 Aug 2004, 09:58 |
|
|
mega-squall 03 Aug 2004, 10:14
f0dder wrote: People writing (and, even worse, distributing) malware should be put to justice I think people who write malware should only do with a very high security level while coding, and still have a B-plan solution, like the amercian lab which was studiing biological viruses that have been burnt out because their was a risk that viruses took out of control. When the virus has been written, then it's sourcecode should be publicly mailed and personnaly mailed to the security responsible, as well as the docs. This way, everybody knows how you get infected, what happens then, and how to desinfect. Developers knows then how to prevent the virus from beeing able to harm any more. This is like a bug report, in more dangerous. But not to be publicly mailed unless the docs EXPLICITLY tells how to desinfect. However, people coding malwares in a malicious way HAVE to be put to justice. _________________ mega-squall |
|||
|
03 Aug 2004, 10:14 |
|
|
crc 03 Aug 2004, 11:03
Quote: yeah different, real protection power is in GPL. The GPL won't protect you from viruses! It's just license, nothing more. |
|||
|
03 Aug 2004, 11:03 |
|
|
BlueOwl 03 Aug 2004, 12:53
Quote: However, people coding malwares in a malicious way HAVE to be put to justice. Why? As long as they do not spread it what does it matter to you? For lots of viruswriters it is just a hobby and they do not do any harm (often do not even share the source code). Here is an article which may be related: http://www.pcmag.com/article2/0,1759,1610730,00.asp |
|||
|
03 Aug 2004, 12:53 |
|
|
crc 03 Aug 2004, 12:56
Writing a virus to study is not malicious IMO. Spreading it *is*, and that's the difference between writing them as a hobby and writing them to cause trouble.
|
|||
|
03 Aug 2004, 12:56 |
|
|
mega-squall 03 Aug 2004, 13:24
BlueOwl wrote: it is just a hobby and they do not do any harm In that case it's not a malicious way ... _________________ mega-squall |
|||
|
03 Aug 2004, 13:24 |
|
|
Gomer73 03 Aug 2004, 15:13
BlueOwl wrote: If the virus could get per-process resident, it could for example infect when you'd put an exe in an archive, and you would not see any difference. Either you don't know what you are talking about or I don't. I don't know of any OS that updates by writing exe's unless it is infected by a virus. I definitely would not build this feature into my OS. There should be no need to change EXE's, period. Exe's could be replaced by a newer version, but not modified. How could a virus get per-process resident? I don't even know what per-process means. And if that is the case, why couldn't the virus just write at anytime, Windows does enough disk access that you wouldn't notice much difference. I don't understand what you mean by putting an exe in an archive. It seems your OS's and uses for a computer are much different than mine. I don't understand what you mean by pop-ups either and buffering., that statement makes no sense to me. Strange lingo to one that isn't familiar with it. I am by no means against knowledge. However, in my view, virus writers do not take into consideration the consequences of their actions. They might not be malicious, but how about the people that read their code? They may not spread it, but as long as the publish it in some form, what prevents somebody who is malicious from spreading it? You do not need source code to understand how a virus works, it is pretty easy to figure out by reading the raw code. The thing is somebody malicious might not have a desire or know-how to write a virus, they then come accross a "hobby" virus writers site and say hey I can use that and spread it around with little or no effort. Yep, virus writers will give the excuse it is to figure out how stuff works. Sure, keep telling yourself that. What good is that knowledge if they don't use it for anything besides writing viruses? They don't use this knowledge to improve the OS, but just write more viruses. Viruses are extremely easy to write and take little discipline. This is one of the reasons why virus writers write viruses. For little effort, they get a big impact. They think they are doing something nobody else has thought of. Get them to try writing a text editor and they wouldn't be able to do it. This is because they don't have the discipline to carry out a long project. For a project like that, you do a lot of coding with little results. I think in essence it is an ego-boost for virus writers because they can say to themselves: you designed an entire OS from scratch, but I am smarter than you because I found a way to exploit a weakness. I think the point here is not to try to decieve ourselves. From the OS side, not to deceive ourselves that malicious people that would write viruses for a developing OS such as Menuet don't exist. For "hobby" virus writers should not deceive themselves into thinking what they are doing is actually difficult to do or that their actions have no negative results. Just my thoughts, ...Gomer73 |
|||
|
03 Aug 2004, 15:13 |
|
|
crc 03 Aug 2004, 15:52
Originally posted by BlueOwl:
If the virus could get per-process resident, it could for example infect when you'd put an exe in an archive, and you would not see any difference. Programs normally make lots of reads and writes to everything (even exes, when updating) and popups would be popping up every second if you would buffer all. And if you would not buffer it all, it could most probably be exploited again. Quote: Either you don't know what you are talking about or I don't. I don't know of any OS that updates by writing exe's unless it is infected by a virus. I definitely would not build this feature into my OS. There should be no need to change EXE's, period. Exe's could be replaced by a newer version, but not modified. As far as I can tell, the idea here is that a modified, e.g., infected, exe could replace an existing one under the right conditions. It's not likely, but it *could* happen, at least in theory. Quote: I don't understand what you mean by pop-ups either and buffering., that statement makes no sense to me. Strange lingo to one that isn't familiar with it. Buffer overruns (which are possible under any OS that executes machine code applications) can be used to execute specific code sequences. Popups would probably be a reference to this. Basically every time you use a buffered function, you can find a way to overrun the buffer. This is a commonly used technique in trojans and viruses. Quote: How could a virus get per-process resident? I don't even know what per-process means. And if that is the case, why couldn't the virus just write at anytime, Windows does enough disk access that you wouldn't notice much difference. I don't understand what you mean by putting an exe in an archive. It seems your OS's and uses for a computer are much different than mine. If a process overruns its buffers, it can execute machine code. In that case, if any buffered routine is at a higher privildge level, it will execute with those permissions. Then the author of the bad app could patch kernel routines, etc. For instance, it could modify the routines that take care of loading an exe, and cause them to add a patch with dangerous code to each newly loaded exe. It could even cause them to be saved, with the changes applied, if the author knew the system well enough. The only way to be completely safe here is to mininize the kernel routines callable user space. Nothing in the kernel should have buffers that you can touch. Buffer sizes should be fixed to prevent overruns. And keep any and all library routines in user space under restricted privilige levels. And use a VM that has no direct interface to the hardware so no machine code is executed, except for what you wrote yourself. |
|||
|
03 Aug 2004, 15:52 |
|
|
Gomer73 03 Aug 2004, 16:39
It could be that not all are familiar with what exactly segments are in the Intel architecture.
A segment allows you to setup a block of memory so that it has a base memory start, a size, and a type. Code segments are read-only and could also be made so that they can't be read at all(though I don't see the value in this), you cannot write to a code segment. Data segments can be also read-only as well if you choose. You have to access memory through a segment. Same thing with executing code. A data segment cannot be executed. If one uses this model, I can't see how buffer overruns can do any damage. Worst case scenario you will overwrite other data, but this data can never be executed. Also, if you are at the limit of your segment, it won't even allow you to overrun the segment, the processor will kick into an exception as soon as you try writing outside the segment. I think these issue basically happen when OS's use the flat model. This is where your segments start at base 0 and all applications are loaded in the same segment, only with different offsets. Data starts at base 0 as well. I don't believe Menuet has these issues(unsure of the setup of it though) since I think it uses a different data segment for each task. As long as your code and data segments don't overlap, buffer overruns could never run any code put into an overrun. |
|||
|
03 Aug 2004, 16:39 |
|
|
BlueOwl 03 Aug 2004, 16:40
I agree with crc, but first of all, I am talking about MenuetOS.
Secondly, Yes I meant that if a virus could intercept write calls (which were used by legitimate update program or alike) it could still infect unnoticed. I meant with popups, messageboxes asking "program.exe is trying to write to another_program.exe; allow?". Actually, limiting buffer sizes won't necessarily stop the problem. Cavity infectors excist which can infect code without making it larger (filling up gaps/ simplifying code). Quote: This is because they don't have the discipline to carry out a long project. Have you ever seen a methamorphic virus? Complicated ones contain thousands of ASM codelines. I can guarantee that there are not many people able to make such a thing. |
|||
|
03 Aug 2004, 16:40 |
|
|
crc 03 Aug 2004, 17:09
Segment permissions do no good if you can bypass them. For instance, under Linux and FreeBSD (and other OSes too) there is a system call called mprotect. Any app can use this to change the memory protection of it's entire address space. Indeed, I used this heavily before finding a better solution for RetroForth 7.0
You can execute code in a data segment. I've seen it done in C programs often enough. I even wrote a small compiler in C that could execute from the data section. It's not always easy, but it can be done. Maybe it's a little harder in assembly, but I doubt it. The x86 was never designed to be a secure architecture, and no matter what you do, someone will find a way around it. Limiting a buffer size can work to prevent buffer overruns though. While not perfect, that method will at least stop most buffer-based attacks from succeeding. |
|||
|
03 Aug 2004, 17:09 |
|
|
SPTH 03 Aug 2004, 18:22
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, ... |
|||
|
03 Aug 2004, 18:22 |
|
| Goto page Previous 1, 2, 3, 4, 5 Next < Last Thread | Next Thread > |
Forum Rules:
|