#foswiki 2016-12-30,Fri

↑back Search ←Prev date Next date→ Show only urls(Click on time to select a line by its url)

WhoWhatWhen
***Vampire0_ has quit IRC (Ping timeout: 268 seconds) [02:41]
.................................. (idle for 2h48mn)
gac410 has left [05:29]
...................................................... (idle for 4h25mn)
vrurg has quit IRC (Quit: vrurg) [09:54]
..................................................... (idle for 4h22mn)
ChanServ sets mode: +o Lynnwood [14:16]
............. (idle for 1h2mn)
ChanServ sets mode: +o gac410 [15:18]
........................................ (idle for 3h18mn)
LynnwoodGood end-of-the-year to everyone! [18:36]
gac410Good end-of-the-year to you too. [18:37]
LynnwoodI'm dealing again with an issue I ran into back in November where a site's password file got hosed. :-(
I _think_ i've found the registration instance where the damage was done.
Just to check: is there anything wrong with a login name to have a period in it? (I don't think so but looking at anything out of ordinary)>
[18:37]
gac410hm What's the sequence of events? foswiki.org has been quite stable, with lots of registrations, and removals. Ah.. we don't use login name.
not that I'm aware of ... period should be supported.
[18:39]
Lynnwoodi would think so... i doubt that's the issue but just checking. [18:39]
gac410Is the .htpasswd file empty, or truncated after a particular user. [18:40]
LynnwoodWhat happens is that at some point, the password file get's trucated. In this case, the front end of the file was lost. [18:40]
gac410Are you running fcgi / mod_perl, and if so, do you have .htpasswd caching enabled along with "detect modiication:
front end. wow. that's really strange.
[18:40]
Lynnwoodah... wait... maybe not the case. [18:41]
yea... that seems to be the case... or else the characters were all corrupted somehow. [18:51]
gac410Are you running 2.1.2 or an older version? [18:51]
LynnwoodI just downloaded the file to examine it and the first line is filled with upside-down question marks. The next line is from later in the file.
this is 2.1.2 i think. i'll double check. This first happened shortly after i upgraded site.
[18:52]
gac410is the site public ... such that it could be exposed to internet attacks / crafted registrations? [18:53]
Lynnwoodconfirmed 2.1.2. [18:53]
gac410hm strange [18:54]
LynnwoodIt is a public site. However, I looked at the access log for any instances of registering and they correspond to what appears to be legitimate registrations.
without giving details, there are several factors i considered there.
the only one that looks at all odd is the one with period in user name.
I do think that registration corresponds with when the damage was done... but i don't think the issue was the user.
user name
[18:54]
gac410The corruption problem we had was in Item13142 - something was changing the default line ending causing the whole file to be read into a single line. [18:58]
FoswikiBothttps://foswiki.org/Tasks/Item13142 [ Item13142: HtPasswd file corruption encountered on Foswiki.org ] [18:58]
gac410Any chance you are using a locally modified password manager? [18:59]
Lynnwoodno [18:59]
gac410had to ask ;) [19:00]
Lynnwoodfor sure... perhaps i should double check but can't think of any reason why i would have touched it, particularly after upgrading the site. [19:01]
gac410the Item13142 issue was really severe - showed up mostly after using the Remove User tools,
And iirc it resutled in a single-line file
[19:01]
LynnwoodWas the content preserved otherwise? [19:02]
gac410Are you using fcgi or mod_perl or ?? [19:02]
Lynnwoodno, not yet.
I was actually looking at setting that up today before this came up.
[19:02]
gac410tbh I don't really recall now. I don't thing it was preserved, as it read it in as a single line, and then parsed and wrote out just one record.
So if my memory is good, we ended up with just the first entry. ... and then possibly other registrations after it. We were under a "bot" registration attack at the time - 10's - 100s a day
[19:03]
LynnwoodIt _does_ appear that much of the file was converted to one one but all the content seems to be corrupted as well as there are no normal characters. [19:04]
gac410Well that bug was from well before unicode support. [19:04]
Lynnwoodnot on this site [19:04]
gac410Hm One other question - Do you speciy a special alternative encoding for .htpasswd - pretty unusual to do so [19:05]
Lynnwoodno. i don't think so. didn't know there was such an option. [19:05]
gac410$Foswiki::cfg{Htpasswd}{CharacterEncoding} = 'utf-8';
[19:05]
Lynnwoodchecking... [19:06]
gac410Y. we don't have a tool to re-encode .htpasswd, so that's an alternative, though strongly not recommended. It's also needed for eg. when a site is running shared .htpasswd ... like we did with t.f.o and f.o, but with different foswiki versions. [19:06]
Lynnwoodthat setting is blank and not enabled. [19:07]
gac410okay. that's the recommended configuration
ie. .htpasswd will be consistent with the store encoding.
[19:07]
LynnwoodWhen I ran into this issue before, I did use some tools to sniff out any possible problem characters. [19:08]
gac410So your site uses login names - has AllowLoginNames enabled?
if the . is in the WikiName, then something is strange as that should not be allowed.
As . is the Web.Topic separator
[19:08]
LynnwoodlAllowLoginNames is enabled [19:10]
gac410Okay - that's one thing different from f.o. [19:10]
Lynnwoodhere's the discussion from the last time this happened: http://irclogs.foswiki.org/bin/irclogger_log/foswiki?date=2016-11-02,Wed [19:10]
gac410BTW you might check revisions of WikiUsers - that might tell you what the last registered users were. Also look in the events.log for "regst" and "register" events [19:11]
Lynnwoodi haven't looked at events.log yet...
i looked at apache log and compared to Main.WebChanges where I identified 4 registrations.
[19:12]
gac410We log register and registration start events. We also log every authentication event [19:12]
Lynnwoodi think i'll check that now...
Btw, I do see something that perhaps should be modified in ResetPasswd.
By default, it loads the current user... but in many (most?) instances, this is figured as "guest" - which when submitted produces an error.
[19:13]
gac410Ah, yea we probably should not bother pre-filling the field on the reset page. [19:17]
Lynnwoody, i think so. [19:17]
gac410Though no exploit there that I can think of [19:18]
Lynnwoodi suspect users having trouble logging in just click on link to that page and then hit button
...without even paying attention to the user field
[19:19]
gac410y [19:19]
LynnwoodIf the field is empty, then a "nicer" error is displayed that the user can't be found. [19:19]
gac410If you open a task we can address it for 2.1.3 Beta 2 [19:19]
Lynnwoodbut with "guest" you get a script error. [19:20]
.... (idle for 16mn)
gac410Lynnwood: ... I don't get a pre-filled user name on ResetPassword ... with or without "AllowLoginName" permitted
See also https://foswiki.org/System/ResetPassword when not logged in.
And if I submit the reset with the field left blank, I get an oopserror, not a script failure: Password reset failed. Can't find user
Okay ... if I manually type in "guest" and press reset, I get "cannot change user passwords using Foswiki::BaseUserMapping at /var/www/foswiki/distro/core/lib/Foswiki/Users/BaseUserMapping.pm line 496."
[19:36]
FoswikiBothttps://trunk.foswiki.org/System/PerlDoc?module=Foswiki::BaseUserMapping [19:38]
gac410so yeah that could be made more friendly, but I'm definitely not seeing that as the default user. [19:38]
Lynnwoodok... the only difference is that i'm using NatSkin.
if i add url param to set skin as pattern, no user name is entered.
[19:40]
gac410Ah. okay ... Gotta engage Micha on that one. [19:40]
Lynnwoodi'll see if NatSkin over-rides that page
yea...
[19:40]
gac410maybe it's something funky going on with NatSkin ... but f.o has > 6100 users registered, and has a fair amount of activity and has been quite stable.
(And I backed up .htpasswd just now, as I'm clearly jinxing things :D )
[19:45]
Lynnwoodconfirmed that NatSkin (via AutoTemplatePlugin) over-rides ResetPassword and auto-populates field with user name. i'm modifying locally but will let Micha know. [19:47]
gac410It probably also overrides the registration page, so might sniff around to see if it's doing anything else that might cause issues. [19:47]
Lynnwoodi'll double check that... but i have a custom registration page with extra fields so don't think it that could be cause.
Lynnwood has hard time imagining how something in registration page itself could cause this...
[19:48]
gac410I agree.
There is a use constant TRACE => 0; option in HtPasswdUser.pm that will trace fairly in-depth password file changes. It might expose passwords to the log. But it might also give you ideas on what's going on if it happens again.
I sincerely hope u are using HtPasswdUser.pm and not the deprecated / broken Apache module
[19:49]
LynnwoodThanks for those ideas... [19:52]
gac410we removed ApachePasswdUser (can't even remember what it was called) from the release [19:53]
Lynnwoodyou're referring to {PasswordManager}, right?
i have it ste to Foswiki::Users::HtPasswdUser
[19:53]
FoswikiBothttps://trunk.foswiki.org/System/PerlDoc?module=Foswiki::Users::HtPasswdUser [19:54]
gac410Okay good Yes. The other one was ApacheHtPasswdUser and it was badly broken "demonstration code" We deprecated it ... and then removed it from 2.0 [19:55]
Lynnwoodwhat is recommended setting for {Htpasswd}{Encoding}? [19:56]
gac410Just leave it un-set.
It's actually commented out in Foswiki.spec, so it is undefined unless really needed.
You could check your .htpasswd file with: perl -nlE 'say if /\P{Ascii}/' < .htpasswd ... To check for non-ascii. And then use the "isutf8" tool to check for valild utf-8
[19:56]
Lynnwoodnot an option. I'm not referring to {Htpasswd}{CharacterEncoding} [19:58]
gac410hang on .. looking [19:59]
LynnwoodFor {Htpasswd}{Encoding}, the default is apache-md5 which is what i've got it do.
...after reading i see that is the default.
[19:59]
gac410{Htpasswd}{CharacterEncoding} should be blank, with the enable box un-checked. (meaning undefined)
Y, {Encoding} should be apache-md5 ... though there are other viable encodings as well. But that one is reasonably secure ... well salted
[20:00]

↑back Search ←Prev date Next date→ Show only urls(Click on time to select a line by its url)