On Mon, 2008-08-25 at 11:57 +0400, Dmitry E. Oboukhov wrote: > NW> An attacker would be insane to select this example as a > NW> vehicle. > > Attacker can use many ways (all variants from this list, for ex), one of > its can work. Why you think that this variant is not work?
Because it is in the documentation, not the script. Didn't you read the reply? It is not a route of attack, it is AN EXAMPLE in the documentation! What kind of attacker is going to assume that a particular user not only has the package installed but has also chosen to use this specific one of a couple of dozen examples available in the doc package that goes alongside this one package, to create a particular file which is itself part of a process that even the most regular user operates once a month at most *and* that the user has not implemented the example in some other script that does various other checks? The number of users who need this particularly specialised example is very small (which is why it is not implemented directly within dfxml-invoice). An attacker would be insane to select this example as a vehicle. The whole point of the package is to support the use of the data in a wider variety of scripts, written by users for themselves. The example exists to show what can be done, not what every user is expected to do. Stop blindly applying your (broken) logic and *think* about the bugs that you are filing, Dmitry. The example is only a problem if a user implements the documentation without thinking *and* uses it on a multi-user system. The idea that this is a grave security issue is ludicrous - you might as well assert that all interpreters must be withdrawn because they can be used in security attacks. I know, let's ban all means of file storage because files can be used in attacks - even better, ban all methods of executing the content of any file, whether in RAM or in storage. No, wait, that's insane. Blind application of logic will end up with a ban on oxygen because it is fatal to all life on earth. The logic is correct, even if all human disease is cured, oxygen will cause the death of every human on earth (over a sufficient period of time) due to the role of oxygen radicals in the ageing process, it still doesn't mean it is correct to apply the result of that logic. If you extrapolate pure logic far enough, every possibility becomes probable. If you allow enough time, every probable risk becomes a certainty. You can't use blind logic to assert risk, the logic must be tempered within the bounds of what is reasonable, what is likely and what is realistic. IMHO, the risk of bugs (including quite a few security ones) due to time_t overflowing in 2038 is far more likely than a real security issue from #496429. That is why pilot-qof (via the QOF library) has 64bit time handling on all platforms but this rather innocent example. It is *not* reasonable to say that even 64bit time is insufficient and that all time must be 128bit or 1024bit or gigabit etc. 64bit already includes enough seconds to encompass a couple of dozen times the (estimated) age of the universe, 32bit time_t comes to an abrupt end in 2038. This about proportionality, reasonable risk and a realistic assessment of security implications. Security measures *must* be proportional to the actual risk. That is the main the problem with this mass bug filing, the security implications are not equal across all packages which have had RC bugs filed against them. Just because your (broken) script has found a pattern, does NOT mean that the pattern is a security risk - it is incumbent on YOU to check the output of each individual pattern match in each individual package and make a sane determination of the actual risk of that pattern in that package. The bug should then detail the *specific risk* within that package, an assessment of why that specific risk in that specific package is actually a problem for that specific package within the normal behaviour of that package. With a release so close, filing RC bugs without due care is, as Steve described in #496386, simply not good enough: "This is far below the quality I expect from a mass bug filing that's been reviewed by debian-devel. Mass bugfilings at RC severity need to be held to a much higher standard than this, particularly when we're in the middle of a release freeze." I take Steve's point that the example could be improved (although I'm not entirely sure what form the change should take so as to not obfuscate the example in security warnings). Such a request for an improved example is NOT a security issue or an RC bug! There is no way that this example should delay the release of Lenny. I'm tempted to close all other bugs filed during this mass bug filing against packages that I use without any further comment or fix or explanation, simply because the mass bug filing itself is so unreasonable. Why should I invest the time trying to determine if the bug is an actual risk when, so far, I have found all instances to have been filed without sufficient care or diligence? If the submitter doesn't care about checking if the bug is real or imagined, why should I believe that the risk is real? Your lack of due diligence has invalidated the entire mass bug filing attempt and undermined every bug you have filed for this supposed problem. IMHO, the only acceptable response to this inept bug filing is for you to immediately close all the bugs you have filed under this mass bug filing so far, go back to the beginning and take the time to make an individual assessment of the individual risk of each package and script that your process has so far identified. Then, in the accepted manner, using '/usr/bin/mass-bug' from devscripts, you post again to debian-devel, including a detailed list of packages, maintainer and uploaders (mass-bug does this for you) against which you PROPOSE to file bugs and give time for responses. According to the responses, you optimise the process further and repeat until there is a consensus that the methodology has done everything reasonable to exclude false positives (including not scanning patterns within embedded documentation like POD). Then, you individually file each bug with a clear description of the problem as it applies to that specific package and you set the severity and tags appropriately for each individual bug. During this process, you may well generate a patch that fixes the problem and you can then attach that to the bug report. This is what I have been doing for the long term mass bug filing for crossbuilding support that I started in November 2007 and which will continue until probably just before the release of Lenny+1. http://bugs.debian.org/cgi-bin/[EMAIL PROTECTED] Status * 59 Outstanding * 2 Pending Upload * 39 Resolved I don't care that it takes longer, it gets better results and is the right way to do a mass bug filing. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
signature.asc
Description: This is a digitally signed message part
