| Ryandor.com http://www.ryandor.com/forum/ |
|
| Windows Vista http://www.ryandor.com/forum/viewtopic.php?f=4&t=2980 |
Page 1 of 1 |
| Author: | Sydius [ Wed Jul 12, 2006 2:16 pm ] |
| Post subject: | Windows Vista |
Just installed it last night. I like it, but it is buggy. |
|
| Author: | Dian [ Wed Jul 12, 2006 2:25 pm ] |
| Post subject: | Re: Windows Vista |
Sydius wrote: Just installed it last night. I like it, but it is buggy.
I cant believe that anything microsoft distributes, could be buggy in any way, what-so-ever. You must have installed it incorrectly. Please re-read the instructions, and try again. |
|
| Author: | Stormcrow [ Wed Jul 12, 2006 4:58 pm ] |
| Post subject: | Re: Windows Vista |
Dian wrote: Sydius wrote: Just installed it last night. I like it, but it is buggy. I cant believe that anything microsoft distributes, could be buggy in any way, what-so-ever. You must have installed it incorrectly. Please re-read the instructions, and try again. Even moreso, I can't believe Syd said he actualy likes a Microsoft product. |
|
| Author: | Dev Viperrious [ Wed Jul 12, 2006 8:33 pm ] |
| Post subject: | |
|
Micro Limp??? Vista is supposed to have high security protection for the computer by reshuffling the cards (files) every time it reboots...I find that highly suspect since it would require a directory/index file to tell it where it placed all the files it moved thus making it just as vulnerable if not more so than all the previous versions. The graphics abilities are also supposed to be greatly enhanced, time will tell on that one. Dev |
|
| Author: | Bmzx007 [ Thu Jul 13, 2006 10:09 pm ] |
| Post subject: | |
I like Vista, its not too bad. But as Syd said, it still has issues. Im going to test out Longhorn Server B2 tonight, so I'll report back on how that goes :P |
|
| Author: | Sydius [ Sun Jul 16, 2006 1:55 pm ] |
| Post subject: | |
It does not need an index file, except in RAM, where it can be better protected. |
|
| Author: | Spudz777 [ Mon Jul 17, 2006 5:33 pm ] |
| Post subject: | |
So it stores the file index in RAM? That sounds like a buffer overflow attack waiting to happen, as well as taking up huge chunks of RAM... Plus, does it read the whole disk and create the index file on boot? Or write the file to disk on shutdown and read it on boot? Either would slow things down quite a bit, plus if you lose power it would have to rewrite the file anyway... Yuck? |
|
| Author: | Sydius [ Tue Jul 18, 2006 11:05 am ] |
| Post subject: | |
So far as I know, it only renamed the system files, and so it only needs an index of those, which is not very big. I do not see how that could give rise to a buffer overflow, either. Do some more research on buffer overflows before you start throwing statements like that around. A list of items does not always mean buffer overflow vulnerability (in fact, it very rarely does, and only when the programmers make a big mistake) -- even more unlikely when the chunk of RAM is protected by the operating system. It may just rename all the files on boot to randomized names, keep an index while running, and then on shutdown, reverse the names. Renaming files is an extremely quick procedure. |
|
| Author: | Dian [ Tue Jul 18, 2006 2:08 pm ] |
| Post subject: | |
I had an overflow while getting a buffer earlier... man, lemme tell you, the entire place was at risk to intrusion, cause I couldnt move for several minutes 
|
|
| Author: | Spudz777 [ Tue Jul 18, 2006 6:03 pm ] |
| Post subject: | |
Buffer overflow vulnerabilities are prevalent in Windows releases. Unless you'd like to say that Microsoft programmers don't make big mistakes? Granted, taking advantage of such a vulnerability is more difficult when that area in RAM is looked after directly by the OS, but it's far from uncommon. If it's only "shuffling" the system files, then it wouldn't be as bad a performance hit once the index is created, only a couple extra RAM reads whenever a system file is needed, so I can see how that would work. In order to execute a successful buffer overflow attack, all a program needs is knowledge of where in RAM it is running, where in RAM its target is, and (possibly, depending on what it's trying to accomplish) the ability to masquerade as a system process. Most OSes don't mind if a program tries to read outside its own memory space, so in this case, it would only need to read the index file, pick out the files it wants to delete, modify, copy, etc., then use system calls (as an already running system service) to do whatever to the files directly. This may be easier said than done, depending on how Vista sets up security, but the idea is quite simple, and very successful. Losing power could still be a major problem... |
|
| Author: | Ryandor [ Tue Jul 18, 2006 11:19 pm ] |
| Post subject: | |
*Eyes glaze over* -Ryandor 
|
|
| Author: | Sydius [ Wed Jul 19, 2006 10:20 am ] |
| Post subject: | |
Spudz777 wrote: Buffer overflow vulnerabilities are prevalent in Windows releases. They are not common. They do happen, but they are not common, especially with today's technology. Especially in the core operating system -- in fact, I have never heard of a single case of a buffer overflow in the core operating system of Windows XP. There was a case of a buffer overflow in the "Plug n Play" service, which would allow administrator-level access to the entire system, but that service is not the core operating system, and would certainly not give you access to the index of system files, if they are stored in RAM like I am assuming. Spudz777 wrote: Unless you'd like to say that Microsoft programmers don't make big mistakes? Granted, taking advantage of such a vulnerability is more difficult when that area in RAM is looked after directly by the OS, but it's far from uncommon. If the vulnerability existed, it would have to be in the portion of the operating system responsible for the index maintenance and querying, and if that vulnerability existed, it would matter little where in RAM the list is. Spudz777 wrote: If it's only "shuffling" the system files, then it wouldn't be as bad a performance hit once the index is created, only a couple extra RAM reads whenever a system file is needed, so I can see how that would work. In order to execute a successful buffer overflow attack, all a program needs is knowledge of where in RAM it is running, where in RAM its target is, and (possibly, depending on what it's trying to accomplish) the ability to masquerade as a system process. That is not how a buffer overflow works at all. A buffer overflow happens when you are asked for input by a routine, and provide too much or incorrect input that causes an internal array to go out of bounds. Spudz777 wrote: Most OSes don't mind if a program tries to read outside its own memory space, so in this case, it would only need to read the index file, pick out the files it wants to delete, modify, copy, etc., then use system calls (as an already running system service) to do whatever to the files directly. This may be easier said than done, depending on how Vista sets up security, but the idea is quite simple, and very successful.
DOS didn't care. Every operating system since will throw an exception at you, terminate your program, and ask if you would like to send a report to Microsoft. Oh, and that is if you somehow get out of the virtual memory mode all programs run in (they get their own address space, completely independent of all other running programs). Well, maybe you're right -- maybe they abandoned the whole "virtual protected memory" scheme and based Vista on some very early version of DOS. |
|
| Author: | Dev Viperrious [ Wed Jul 19, 2006 5:29 pm ] |
| Post subject: | |
Microgimp was supposed to have moved away from DOS with Windows XP. DOS based systems will never be secure. Dev |
|
| Author: | Sydius [ Thu Jul 20, 2006 8:48 am ] |
| Post subject: | |
Dev Viperrious wrote: Microgimp was supposed to have moved away from DOS with Windows XP.
DOS based systems will never be secure. Dev They did. |
|
| Page 1 of 1 | All times are UTC - 7 hours [ DST ] |
| Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/ |
|