Saved Bookmarks
| 1. |
Solve : Mozilla or Sun/Oracle?? |
|
Answer» 09/16/2013 09:48 PM Mozilla Firefox 24.0 Final Secure your **** software and leave us alone for a while!!!!! While I can see where you are coming from with this, It's easier said than done. It's the equivalent of asking Doctors and scientists to come up with a vaccine that will 'secure' (immunize) us from all viruses and bacteria. It's just not possible. In order to create a vaccine you need a sample of the infectant- pretty similar situation for Fighting security problems. There are some techniques that can be used to try to cut down on things such as Buffer Overflows and other more easily mitigated problems, but sometimes the problems are so non-obvious that to command they be fixed before they are even discovered is to essentially demand clairvoyance. The "problem" is that when a Programmer writes software, they USUALLY write it originally considering what a well-intentioned user will be doing; for example, a routine that reads in XML and parses values using a library might assume the XML is valid and simply Error out if not. We don't generally start writing code with the express intention of considering how malicious inputs would affect our logic, because if it doesn't work to begin with, how secure it is doesn't matter. Instead we add "security" afterwards. And nobody can ever have enough understanding of all the facets of development to be able to point at, say, the specific method being used to load an XML file as being a vulnerability, because it turns out that due to how that library is structured and how it's API is based on a former JSON api, you can pass a JSON file directly to it and execute arbitrary Javascript code within the context of the application when the application loads the XML (that is just an example). It's basically like building a boat. No matter how careful you are, you can never be sure how waterproof it is until you stick it in water. And even if it floats for a day, or a month, or years, somebody might come along and find a a weak truss or beam, and to the bottom it goes.Good reply BC. My main gripe is with Mozilla. I can understand the slight annoyance of updating to a new version v23.5 > v24.0. It's all of the little security and stability fixes in between that get to me. They now allow for 'No Restart' add-on installs. Why can't they figure out a 'No Restart' fix like when going from v23.1 to v23.2? Java updates have slowed down. Let's hope it stays that way for a while.Quote from: evilfantasy on September 17, 2013, 08:11:17 AM Good reply BC. My main gripe is with Mozilla. I can understand the slight annoyance of updating to a new version v23.5 > v24.0. It's all of the little security and stability fixes in between that get to me. They now allow for 'No Restart' add-on installs. Why can't they figure out a 'No Restart' fix like when going from v23.1 to v23.2? Same reason you can put fuzzy dice on your rear-view mirror without stopping and shutting off your car but you have to shut it off to replace the engine block The tricky part is of course that we aren't talking about add-on bits of Javascript, but rather the Executable behind the whole shebang. On windows, you cannot delete or replace a running executable with another. The closest you can get would be to rename the running executable to some other name, save the updated version, launch it, and have the existing executable exit. The tricky part is that you simply cannot "switch" from running one executable to another- it's not even really a CASE of complexity, but even with the same program it's like trying to jump from page 300 of harry potter to page 301 of Sun Tzu's The Art of War- It just won't make sense. Even if it was possible and all the complex part of actually updating all code segment pointers in memory to point to the new executable was doable, you've still got the issue that the new executable is now dealing with the old executable's data. Let's imagine a simple program with a structure that tracks update information while it is running, perhaps from a remote database: Code: [Select]struct UpdateInfo{ char* Version; char* ProgramName; char* UpdateURL; int UpdateType; } Now imagine a version .x is released to address a security issue, which is dealt with by adding a Security Token to each UpdateInfo structure: Code: [Select]struct UpdateInfo{ char* Version; char* ProgramName; char* UpdateURL; int UpdateType; int SecurityToken; } Updating a running program would be impossible; the existing program uses a structure that is 16 Bytes long (on 32-bit), whereas this structure uses an extra 4 bytes. This is going to cause problems. Imagine if the program normally keeps an array of these structures in memory, the old one will be laid out sequentially- If the program was to suddenly be updated with new code, the new code will try to access the values incorrectly, because it assumes the structure has a SecurityToken field. Essentially, all the data get's corrupted, and the program needs a restart anyway. To make matters even worse, Even compiling the same source with the same compiler can result in compiler-generated structures to DIFFER in size and arrangement enough to make this a problem. Well here is an answer as to why so many updates. Keeping up with the Joneses... October 20, 2013 Quote When Mozilla announced that it would change the Firefox release model to one that it called Rapid Release Model, it was seen by part of the browser's user base to compete with the Google Chrome browser which outpaced Firefox release wide. Full article: Mozilla considers switching to a 9 week release schedule |
|