So you saying if I bruteforce a CAS server with a common password list and achieve an authentication within the user h*. that is not a authentication bypass? nice, in your world maybe.
You can cry, kicking around, panic, call me incompetent or whatever ad hominem you want, but this still is an authentication bypass. If you dont agree, ask the dev team to rollback the update, and ask mitre to revoke the CVE. And last, this flame will lead us to nowhere, haters gonna hate and i will not feed this troll anymore. On Fri, Jan 23, 2015 at 6:25 PM, Paul B. Henson <[email protected]> wrote: > > From: J. Tozo > > Sent: Friday, January 23, 2015 10:28 AM > > > > I was not aware of the issue wasn't present in the fast bind ldap > authentication > > because I discovered it in my own deployment, a year ago. > [...] > > I thought reasonable to write a small report about it, the > > way i see it could hit my own environment. > > If you did not fully understand the vulnerability, you should not have > requested a CVE, and you should not have posted an inaccurate announcement > to a security list. What would have been "reasonable" would have been to > post this to the cas-users mailing list for discussion. There is an > (understandable) assumption that "security researchers" will actually > *research* a vulnerability before requesting a CVE, and post an accurate > analysis. You posted a poorly written half-ass embarrassment with a > flagrantly false title which didn't even come close to rigorously > describing the underlying issue. > > > You cant deny Its a authentication issue in an authentication system > > I never denied it's an authentication bug in an authentication system. > What I *said* was that it is in no way an authentication *bypass*. Let me > help you out: > > http://www.thefreedictionary.com/bypass > > In a security report such as you posted, typically the definition used > would be "A means of circumvention". Tell me, how exactly does this issue > let you "circumvent" authentication? You need to know a sufficient amount > about the username to construct a wildcard that matches it, exactly it, and > nothing else in the user base, *and* you need to know the password for that > user. That's not bypassing or circumventing authentication. I get the > impression you are not a native English speaker, which is excusable, but if > you want to play in the big leagues and post vulnerability reports to > security mailing lists, you need to understand the terminology sufficiently > to accurately use it. > > > if you really believe that there is no practical > > security implication, so we have nothing to talk. > > You have described no practical security implications, other than a > fanciful attempt at how it might be used in a brute force attack. I do not > believe there is any practical security implications because none have been > demonstrated. *You* are the one that seems to think this is a serious > security issue, *you* are the one that needs to explain why. So clearly if > we have nothing to talk about, it is because *you* can't think of any. > > > if you spent two hours to > > figure out if your system is vulnerable or not I think you have another > problem > > I did not spend two hours figuring out if my system is vulnerable. Once I > reviewed in more detail your report it was fairly obvious it was not. What > I did spend two hours doing was actually analyzing the problem, what you > should've done before reporting it, and posting to the mailing list > regarding it. The only problem I had was wasting time cleaning up the mess > you made with an unprofessional and incompetent security report. > > > you do not like the way its written, pay someone to write the security > reports as > > you wish (or do it by yourself) and stop complaining about to do your > job in a > > public mail list, if its not good then just quit. > > If you don't want to receive constructive criticism, maybe you shouldn't > post your crap on public mailing lists. > > It's pretty clear you are just some kid who thought it would be "cool" to > get a CVE and publish a security report. I'm frankly surprised Mitre even > gave you one, I thought there was at least some limited assessment of > reports before assignment. So your response to "you did a bad job on this" > is "I would've done it better if you paid me"? Hah. I'm not complaining > about my job, I'm complaining about yours 8-/. Like it or not, when you > request a CVE and publish an official report, you are beholden to the > community to do a reasonable job and there are actual consequences to your > actions. > > The next time you decide to publish a security issue, I hope for your sake > and everyone else's you actually spend the time to analyze and fully > understand it, and write an accurate report with a reasonable assessment of > the true vulnerability and exposure risks. > > -- > Paul B. Henson | (909) 979-6361 | http://www.cpp.edu/~henson/ > Operating Systems and Network Analyst | [email protected] > California State Polytechnic University | Pomona CA 91768 > > > > -- > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > > -- Grato, Tozo -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
