# Security Diligence - Thread: https://externals.io/message/72398 - Original archive: https://news-web.php.net/php.internals/72398 - Started by Lester Caine on 2014-02-08T11:52:24+00:00 - Messages: 15 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #72398 — Lester Caine — 2014-02-08T11:52:24+00:00 URL: https://externals.io/message/72398#72398 I think an explanation of my recent posts is probably due. The bulk of my income is from council and other local authority customers who are required to jump through many often difficult to identify hoops. They are currently being put through another round of 'security assessments' and I had a second visit to a site which we have yet to upgrade from PHP5.2 earlier this week. The system is doing exactly what the 'customer' wants ( the client is the customer services team ), and while the IT department has been providing network access since it was installed in 2007, it has no outside access other that a VPN/VNC link so I can carry out maintenance. As a result it has not been necessary or easy to upgraded to later 'security patches'. It's the last of my 'CMS' sites that I have to upgrade to PHP5.4 and that was the discussion before Xmas, but the IT department have now realised that they should be managing the network better :) Driven by their current security assessment, linked to removing Windows XP from it. Since two of the CMS machines are running XP, these will need to be replaced, but it is the Apache/PHP stack which the 'security consultant' has been targeting insisting that only a CURRENT version of both will be acceptable, and PHP5.4 is not current in his eyes despite it getting security updates independent of PHP5.5. I am more than happy that within the constraints applied I have maintained the PHP5.2 setup as 'safe' as I can and since these sites are all ring fenced inside the site network personally I do not see a problem. This view is actually supported by the IT staff, it is the independent consultant who is now putting up objections to our continuing to supply the CMS service. Unpatched reported security problems are one of his objections and timed attack was one brought up probably because it's discussion is currently happening! We are currently trying to work out how to move forward, and since the service provides an essential part of the handling of visitors there is a desire by the users to maintain it ;) Why is this all so futile? The system is still using the same 4 digit 'pin number' to identify a staff id that was instigated when the system was first designed back in 1992, and when many access positions were just numeric pads with small displays! No sensitive data is stored ... ( Firebird's password is still limited to 8 characters for historic reasons, so the length is a known and the hash decode is designed to check all characters even if an earlier compare fails ... so maintains a fixed test time ) -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk --- ## #72399 — Nikita Popov — 2014-02-08T12:08:42+00:00 URL: https://externals.io/message/72398#72399 · In reply to: #72398 > I think an explanation of my recent posts is probably due. > > The bulk of my income is from council and other local authority customers > who are required to jump through many often difficult to identify hoops. > They are currently being put through another round of 'security > assessments' and I had a second visit to a site which we have yet to > upgrade from PHP5.2 earlier this week. The system is doing exactly what the > 'customer' wants ( the client is the customer services team ), and while > the IT department has been providing network access since it was installed > in 2007, it has no outside access other that a VPN/VNC link so I can carry > out maintenance. As a result it has not been necessary or easy to upgraded > to later 'security patches'. > > It's the last of my 'CMS' sites that I have to upgrade to PHP5.4 and that > was the discussion before Xmas, but the IT department have now realised > that they should be managing the network better :) Driven by their current > security assessment, linked to removing Windows XP from it. Since two of > the CMS machines are running XP, these will need to be replaced, but it is > the Apache/PHP stack which the 'security consultant' has been targeting > insisting that only a CURRENT version of both will be acceptable, and > PHP5.4 is not current in his eyes despite it getting security updates > independent of PHP5.5. > > I am more than happy that within the constraints applied I have maintained > the PHP5.2 setup as 'safe' as I can and since these sites are all ring > fenced inside the site network personally I do not see a problem. This view > is actually supported by the IT staff, it is the independent consultant who > is now putting up objections to our continuing to supply the CMS service. > Unpatched reported security problems are one of his objections and timed > attack was one brought up probably because it's discussion is currently > happening! We are currently trying to work out how to move forward, and > since the service provides an essential part of the handling of visitors > there is a desire by the users to maintain it ;) > > Why is this all so futile? > The system is still using the same 4 digit 'pin number' to identify a > staff id that was instigated when the system was first designed back in > 1992, and when many access positions were just numeric pads with small > displays! No sensitive data is stored ... > > ( Firebird's password is still limited to 8 characters for historic > reasons, so the length is a known and the hash decode is designed to check > all characters even if an earlier compare fails ... so maintains a fixed > test time ) > I'm sorry, but how does this relate to the internals mailing list? Thanks, Nikita --- ## #72401 — Andrea Faulds — 2014-02-08T13:03:04+00:00 URL: https://externals.io/message/72398#72401 · In reply to: #72399 > I'm sorry, but how does this relate to the internals mailing list? I might be reading it wrong, but I think Lester's saying "don't change PHP in ways that force people to make their code secure, because it doesn't matter if *my* code's insecure". -- Andrea Faulds http://ajf.me/ --- ## #72400 — Lester Caine — 2014-02-08T13:04:33+00:00 URL: https://externals.io/message/72398#72400 · In reply to: #72399 Nikita Popov wrote: > On Sat, Feb 8, 2014 at 12:52 PM, Lester Caine > wrote: > > I think an explanation of my recent posts is probably due. > > The bulk of my income is from council and other local authority customers > who are required to jump through many often difficult to identify hoops. > They are currently being put through another round of 'security assessments' > and I had a second visit to a site which we have yet to upgrade from PHP5.2 > earlier this week. The system is doing exactly what the 'customer' wants ( > the client is the customer services team ), and while the IT department has > been providing network access since it was installed in 2007, it has no > outside access other that a VPN/VNC link so I can carry out maintenance. As > a result it has not been necessary or easy to upgraded to later 'security > patches'. > > It's the last of my 'CMS' sites that I have to upgrade to PHP5.4 and that > was the discussion before Xmas, but the IT department have now realised that > they should be managing the network better :) Driven by their current > security assessment, linked to removing Windows XP from it. Since two of the > CMS machines are running XP, these will need to be replaced, but it is the > Apache/PHP stack which the 'security consultant' has been targeting > insisting that only a CURRENT version of both will be acceptable, and PHP5.4 > is not current in his eyes despite it getting security updates independent > of PHP5.5. > > I am more than happy that within the constraints applied I have maintained > the PHP5.2 setup as 'safe' as I can and since these sites are all ring > fenced inside the site network personally I do not see a problem. This view > is actually supported by the IT staff, it is the independent consultant who > is now putting up objections to our continuing to supply the CMS service. > Unpatched reported security problems are one of his objections and timed > attack was one brought up probably because it's discussion is currently > happening! We are currently trying to work out how to move forward, and > since the service provides an essential part of the handling of visitors > there is a desire by the users to maintain it ;) > > Why is this all so futile? > The system is still using the same 4 digit 'pin number' to identify a staff > id that was instigated when the system was first designed back in 1992, and > when many access positions were just numeric pads with small displays! No > sensitive data is stored ... > > ( Firebird's password is still limited to 8 characters for historic reasons, > so the length is a known and the hash decode is designed to check all > characters even if an earlier compare fails ... so maintains a fixed test time ) > > > I'm sorry, but how does this relate to the internals mailing list? Hopefully to put some of the discussions into context of where they fit in the real world. Is the 'timing attack' or problems created by an 'insecure' random number a practical proposition? The only physical proof that I have seen presented for the 'timing attack' is 10 years old and relates to a 'small local network'? Processor speed has increased a little in 10 years and we now tend to work in 64bit chunks rather than 8 or 16bit? Although that does also enhance the power of the hackers ... So discussing something based on timing 8bit characters seems a little strange? Firebird code dropped the 10 year old process a few versions back. I was trying to establish where the risk was in PHP and while I am more than happy it does not exist in my own applications, while it remains an 'unpatched security risk' others will not accept that fact. What is still missing from the discussion is the level of risk these 'security problems' present? Grounding the security RFC's in a little factual base would be appreciated so that proper defence can be presented when required. Obviously 'fix in X' is ideal, but only if the full risk has been assessed? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk --- ## #72402 — Nikita Popov — 2014-02-08T13:55:42+00:00 URL: https://externals.io/message/72398#72402 · In reply to: #72400 > Hopefully to put some of the discussions into context of where they fit in > the real world. Is the 'timing attack' or problems created by an 'insecure' > random number a practical proposition? The only physical proof that I have > seen presented for the 'timing attack' is 10 years old and relates to a > 'small local network'? Processor speed has increased a little in 10 years > and we now tend to work in 64bit chunks rather than 8 or 16bit? Although > that does also enhance the power of the hackers ... So discussing something > based on timing 8bit characters seems a little strange? Firebird code > dropped the 10 year old process a few versions back. I was trying to > establish where the risk was in PHP and while I am more than happy it does > not exist in my own applications, while it remains an 'unpatched security > risk' others will not accept that fact. What is still missing from the > discussion is the level of risk these 'security problems' present? > Grounding the security RFC's in a little factual base would be appreciated > so that proper defence can be presented when required. Obviously 'fix in X' > is ideal, but only if the full risk has been assessed? > If your system has many other open security concerns, then yes, timing attacks are most certainly the least of your worries and you are very welcome to ignore this issue until you have resolved the more pressing ones. While I certainly appreciate working with secure software, it is not a concern of this mailing list or its members whether or not you implement mitigations against certain cryptographic attacks. It *is* however our concern to provide the necessary means for the people who *do* wish to implement the necessary safe-guards. Also, I strongly suspect that you don't have sufficient cryptanalytic background to assess the severity of certain attack vectors. While remote string comparison timing attacks might be considered an exotic concern by some people, usage of an unsuitable random number generator in the wrong context is a most severe and typically easily exploitable vulnerability. Dismissing it so easily certainly creates the impression that you have a somewhat skewed perception of the severity of some attacks. You might consider the possibility that your security consultant, given his line of work, has a better understanding of application security than you do. Thanks, Nikita --- ## #72403 — Lester Caine — 2014-02-08T14:23:26+00:00 URL: https://externals.io/message/72398#72403 · In reply to: #72401 Andrea Faulds wrote: > > > […] > > I might be reading it wrong, but I think Lester's saying "don't change PHP in > ways that force people to make their code secure, because it doesn't matter if > *my* code's insecure". You are reading me wrong - as is Nikita ... My own code is doing exactly as it has done for many years now with a level of security that the customer is happy with. Adding any more is unnecessary, but 'security advisors' dictate otherwise without actually accessing the risk! But what I'm asking for is that the documentation of the attempts to fix these perceived threats includes just a little more information so those of us who are not so 'expert' can better understand the nature of the risk? Simply quoting third party articles like the wikipedia one does not address how a risk actually relates to PHP. Specifically looking at the 'timing attack', as I understand it, if a comparison process scans all elements and simply sets a flag when failure is detected which is not used until all characters have been processed. Which is the reason for establishing 'safely' the number of characters involved. Using 64bit functions rather than 32bit will also change the way that process works? Much of the difficulty I have with PHP these days is simply trying to understand why the 'new' method of working is better than what we did 10 or more years ago. Good examples of practice is still very lacking even in the latest documentation, and what goes into rfc's these days is the basis for updating the main documentation? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk --- ## #72404 — Pierre Joye — 2014-02-08T14:26:44+00:00 URL: https://externals.io/message/72398#72404 · In reply to: #72403 > Andrea Faulds wrote: > > […] > > > You are reading me wrong - as is Nikita ... > My own code is doing exactly as it has done for many years now with a level > of security that the customer is happy with. Adding any more is unnecessary, > but 'security advisors' dictate otherwise without actually accessing the > risk! > But what I'm asking for is that the documentation of the attempts to fix > these perceived threats includes just a little more information so those of > us who are not so 'expert' can better understand the nature of the risk? > Simply quoting third party articles like the wikipedia one does not address > how a risk actually relates to PHP. > > Specifically looking at the 'timing attack', as I understand it, if a > comparison process scans all elements and simply sets a flag when failure is > detected which is not used until all characters have been processed. Which > is the reason for establishing 'safely' the number of characters involved. > Using 64bit functions rather than 32bit will also change the way that > process works? > > Much of the difficulty I have with PHP these days is simply trying to > understand why the 'new' method of working is better than what we did 10 or > more years ago. Good examples of practice is still very lacking even in the > latest documentation, and what goes into rfc's these days is the basis for > updating the main documentation? Lester, this is not a support list. It is your good right to stick with dead PHP versions and 10 years old code (whether it is your choice or not), but it is definitively not good to constantly posts totally off topic posts, replies or complains about what we do or don't. It is even more annoying in cases where you clearly do not understand the underlying reasons of one feature or another. That being said, I would love to see you actually contribute something for a change. Cheers, -- Pierre @pierrejoye | http://www.libgd.org --- ## #72405 — padraic.brady@gmail.com — 2014-02-08T14:59:16+00:00 URL: https://externals.io/message/72398#72405 · In reply to: #72400 Hi, > Hopefully to put some of the discussions into context of where they fit in > the real world. Is the 'timing attack' or problems created by an 'insecure' > random number a practical proposition? The only physical proof that I have http://phpsecurity.readthedocs.org/en/latest/Insufficient-Entropy-For-Random-Values.html I wrote that as detailed as I could for a general audience. The weaknesses of various PRNGs has been exhaustively studied. > seen presented for the 'timing attack' is 10 years old and relates to a My blog references research from 2010 and I've referenced blog article and two live talks from around the same year in an earlier email to you. You keep insisting on having physical proof in a realm of study where the research must be carried out both legally and ethically, and actual exploits are rarely disclosed by the criminals who use them. The exploit was proven to be practical which means it has surpassed the bar where it needs to be actively defended against. There was no physical proof that you could hack a refrigerator in 2013 but we've already had a long history of warning people about default passwords and poor configuration of home devices. Under your logic, that would mean we have no need to audit and secure refridgerators. There was no physical proof that an attack had ever occured. Of course, that line of thinking looks remarkably poor when someone actually does hack a refridgerator, because all those security people were right afterall. This really happened - it got detected (not publicised by the hacker!) by a research team: http://www.businessinsider.com/hackers-use-a-refridgerator-to-attack-businesses-2014-1 > 'small local network'? Processor speed has increased a little in 10 years > and we now tend to work in 64bit chunks rather than 8 or 16bit? Although > that does also enhance the power of the hackers ... So discussing something > based on timing 8bit characters seems a little strange? Firebird code > dropped the 10 year old process a few versions back. I was trying to > establish where the risk was in PHP and while I am more than happy it does > not exist in my own applications, while it remains an 'unpatched security > risk' others will not accept that fact. What is still missing from the > discussion is the level of risk these 'security problems' present? Grounding That's a loaded gun because nobody here has audited your application so I can't assess the risk of any given vulnerability for your specific context. If I assume a worst case scenario, e.g. passwords hashed using MD5, then a timing attack might well be high risk since reversing the hash is so simple. If you use bcrypt, the risk would be lower but you'd still need to go ask users to change their passwords and suffer the negative publicity that may prompt. If you create CSRF tokens using `mt_rand()`, again the risk would be higher compared to using a strong random source - read the book chapter. Of course how are you interpreting risk? Is it the possibility of an attack occuring, or the possibility of an attack being successful? The general principle is that the former is a given. As I implied before, a lot of people didn't take MITM attacks as seriously as they should have until Edward Snowden came along. That erroneous sense of priorities is something we should try not to fall victim to. You need to get out of the box where security is your enemy. It's an evolving animal and PHP 5.6 is evolving to meet that challenge. Your auditor is perfectly entitled and correct to raise questions over PHP 5.2. He's correct to raise concerns over timing attacks. He's doing his job. If he didn't raise and press those concerns, I'd fire him in favour of someone more competent. >Why is this all so futile? >The system is still using the same 4 digit 'pin number' to identify a staff id that was instigated >when the system was first designed back in 1992, and when many access positions were just >numeric pads with small displays! >No sensitive data is stored ... Unless you own the data, you don't get to say it's not sensitive. It's not your data. Is your place of work in the habit of releasing Staff IDs to the public so I can ring some poor ignorant soul at a service desk and beg them to reset my passwords inside your network? Is it in the habit of disclosing on a public forum that it runs vulnerable software that protects Staff IDs so that I can find that in a Google search and start winding up my social engineering cannon and penetration skills? Your consultant is trying to bolster security and this is unlikely to be the first time they've met resistance to their recommendations. It's actually quite a common part of the job, and it's also why consultants get called in in the first place - to be independent of your concerns and those of the IT dept so that they can offer an objective expert opinion. In their view, you are the refrigerator. I can be a harsh judge, but don't take this the wrong way. You need to put a little trust in the expertise of others and not put it all on you. When security researchers are running scared over an issue, they usually don't do so without some compelling motivation. By all means, do your own research, but you need to also develop a sense of risk and a skill in gauging the implications of any given threat. You see PHP 5.2 as being acceptable. I see it as a frickin' bomb waiting to go off. Yet, we both agree that it's not secure? That our risk assessment differs significantly is probably putting it mildly ;). -- Pádraic Brady http://blog.astrumfutura.com http://www.survivethedeepend.com Zend Framework Community Review Team Zend Framework PHP-FIG Representative --- ## #72407 — Thomas Hruska — 2014-02-08T16:14:28+00:00 URL: https://externals.io/message/72398#72407 · In reply to: #72404 > Lester, this is not a support list. > > It is your good right to stick with dead PHP versions and 10 years old > code (whether it is your choice or not), but it is definitively not > good to constantly posts totally off topic posts, replies or complains > about what we do or don't. It is even more annoying in cases where you > clearly do not understand the underlying reasons of one feature or > another. > > That being said, I would love to see you actually contribute something > for a change. How about giving Lester a hard-and-fast deadline to contribute something useful by? (Being sure to clearly define "useful" in the process.) If he fails to meet the expectations by the deadline, he gets unceremoniously booted off the list. But who am I to make such a suggestion? Make the same rule applicable to everyone who hasn't contributed something useful, which inevitably would apply to me as well. I'm cool with that though. I've got at least one thing I'd like to see in PHP and it would force the issue thus causing me to actually sit down and hammer out the code I've got good intentions to write but never seem to get to. -- Thomas Hruska CubicleSoft President I've got great, time saving software that you will find useful. http://cubiclesoft.com/ --- ## #72406 — Lester Caine — 2014-02-08T16:17:40+00:00 URL: https://externals.io/message/72398#72406 · In reply to: #72404 Pierre Joye wrote: > > […] > Lester, this is not a support list. > > It is your good right to stick with dead PHP versions and 10 years old > code (whether it is your choice or not), but it is definitively not > good to constantly posts totally off topic posts, replies or complains > about what we do or don't. It is even more annoying in cases where you > clearly do not understand the underlying reasons of one feature or > another. > > That being said, I would love to see you actually contribute something > for a change. Currently the material in question is being discussed on this list, and some people obviously understand what the risks are and when pressed pass on that information, but we should not have to ask for clarification. That material should be the basis of the rfc that is being discussed! If the very basis of a problem is not documented then how can it be signed off? The details have been fairly well covered on this list, but moving it forward it needs to be reflected in the documentation. Your own changes to selection of random number sources is quite complex and perhaps we don't need to understand the details, but it should be easier to access direct from the documentation rather than having to interpret third part documents. Simply linking those third part documents may be all that is needed, but how often do they become unavailable later ... wikipedia have killed a number of software related articles. Perhaps when I've managed to get all of not only my own code but other peoples code into a state where it will run on a modern PHP installation, then I might actually be able to find time to put my own improvements forward. My current contribution is as it always has been ... trying to help users get up to date with a continually moving target :( The latest 'problems' are just taking time I don't have to check through if there even is a problem. It will be fixed in a later version of PHP but nowadays that is just not good enough for some people :( I am NOT trying to maintain PHP5.2, it is just there is still a large volume of material that despite what others seem to think will not 'just run' on even 5.3 and now we are getting new 'risks' which may need patching in code that has been updated. If there was an easier way of 'upgrading' then there would not be such a backlog of code still needing converting? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk --- ## #72408 — padraic.brady@gmail.com — 2014-02-08T16:31:29+00:00 URL: https://externals.io/message/72398#72408 · In reply to: #72407 Hi, > > > […] > > > How about giving Lester a hard-and-fast deadline to contribute something > useful by? (Being sure to clearly define "useful" in the process.) If he > fails to meet the expectations by the deadline, he gets unceremoniously > booted off the list. The guy posed some doubts on the validity of what two RFCs intended to do in PHP 5.6. It might be off-topic as not being directly linked to the RFC, but going overboard isn't going to change matters. If you really want to change someone's habits you need only ignore them ;). In this case, I responded because drilling some sense of security into programmers is something I view as important (as my blog attests). It's worth having a response on the list for the record for anyone else harbouring unwritten doubts about the efforts of the RFC authors, but are not keen on airing them. The RFCs do imply some awareness of security and that's largely unavoidable unless each and every RFC needs to be a 1000 page masterwork ;). Paddy -- Pádraic Brady http://blog.astrumfutura.com http://www.survivethedeepend.com Zend Framework Community Review Team Zend Framework PHP-FIG Representative --- ## #72409 — Lester Caine — 2014-02-08T16:48:13+00:00 URL: https://externals.io/message/72398#72409 · In reply to: #72408 Pádraic Brady wrote: > The RFCs do imply some awareness of > security and that's largely unavoidable unless each and every RFC > needs to be a 1000 page masterwork;). Since 'security experts' tend not to wait for fixes to be produced before publishing exploits all I am looking for in this case is enough help in the rfc's to assess if action is required before fixes ARE published! And I hope that since these are security fixes that they are pushed back as far as PHP5.3 since this is still under support for security fixes? It is even more important if the fixes are not being rolled back that the extent of the risk is recorded well enough for users to understand the risk? Are these sort of security issues 'support' issues rather than 'internals'? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk --- ## #72410 — Rasmus Lerdorf — 2014-02-08T17:09:39+00:00 URL: https://externals.io/message/72398#72410 · In reply to: #72403 > > Specifically looking at the 'timing attack', as I understand it, if a comparison process scans all elements and simply sets a flag when failure is detected which is not used until all characters have been processed. Which is the reason for establishing 'safely' the number of characters involved. Using 64bit functions rather than 32bit will also change the way that process works? I think the one simple detail you are missing is that many/most string comparisons will short-circuit as soon as it hits a character that doesn't match. If you think about that a little bit I am sure you can think of a nice algorithm for narrowing in on the password character by character. That is, if 'aaaa' consistently takes longer to compare against the password compared to 'bbbb' then there is a good chance that the first character of the password is 'a'. Looking at the firebird implementation that seems to be the case there as well. Of course, network jitter and other factors make this a complicated attack, but that doesn't change the fact that there is a faint signal there and with enough iterations it has been proven to be possible to separate that signal from the noise. As a fun little experiment for yourself, try implementing an iterative timing attack against your local Firebird database password and see if you can find the signal in the noise. -Rasmus --- ## #72411 — padraic.brady@gmail.com — 2014-02-08T17:23:21+00:00 URL: https://externals.io/message/72398#72411 · In reply to: #72409 Hi, > Pádraic Brady wrote: > > […] > > > Since 'security experts' tend not to wait for fixes to be produced before > publishing exploits all I am looking for in this case is enough help in the > rfc's to assess if action is required before fixes ARE published! Good security people will always await fixes before publishing publicly so long as the wait is not unreasonable for the target sample of cases. That's the tendency unless you have data to the contrary? I'm pretty sure those references I provided earlier point at the researchers in each case reporting to open source projects prior to publishing their research. Obviously, researchers can't report to every single open and closed source library and app that exists but they do make a best effort to get the word out. > And I hope that since these are security fixes that they are pushed back as > far as PHP5.3 since this is still under support for security fixes? It is > even more important if the fixes are not being rolled back that the extent > of the risk is recorded well enough for users to understand the risk? These are not vulnerabilities within PHP but in userland code. The RFCs will make it easier for userland code to be secure out of the box, but userland code should already have such issues patched. I don't see any reason to backport the RFCs unnecessarily - you can make arguments for adding anything useful to older versions not just for security. Paddy -- Pádraic Brady http://blog.astrumfutura.com http://www.survivethedeepend.com Zend Framework Community Review Team Zend Framework PHP-FIG Representative --- ## #72413 — Lester Caine — 2014-02-08T21:15:28+00:00 URL: https://externals.io/message/72398#72413 · In reply to: #72410 Rasmus Lerdorf wrote: > > > […] > > I think the one simple detail you are missing is that many/most string comparisons will short-circuit as soon as it hits a character that doesn't match. But why on earth on 64 bit processors are we still comparing 'byte by byte'? From the Firebird list ... > Ok, let's look at theory: to let this attack to be possible there must me a correlation > between system response time and the distance between attempted password and right > password in any functional space. I can imagine encrypting algorithm for which it is true, > but SHA1 used in Firebird or MD5 used in Linux are different. They work not with every > symbol of password and key separately, but with whole fixed size array of bytes, filling > the rest of the buffer with zeros or salt. In this case (as I already said) there is no > correlation between working time and buffer content (O(N) = N/sizeof(buffer) which for > N I would say that your passwords are out of danger. Even on a 32bit system you would be comparing 4 bytes at a time not one ... The attack will only work if one slowly compares a byte at a time? > If you think about that a little bit I am sure you can think of a nice algorithm for narrowing in on the password character by character. That is, if 'aaaa' consistently takes longer to compare against the password compared to 'bbbb' then there is a good chance that the first character of the password is 'a'. Looking at the firebird implementation that seems to be the case there as well. Of course, network jitter and other factors make this a complicated attack, but that doesn't change the fact that there is a faint signal there and with enough iterations it has been proven to be possible to separate that signal from the noise. > > As a fun little experiment for yourself, try implementing an iterative timing attack against your local Firebird database password and see if you can find the signal in the noise. While an 8 character password is considered unsafe, it is only a single compare on a 64 bit system? But then this is one of the areas which then causes problems if you now want to use multi-byte characters :( -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk