[sr #111093] Account Registration page information disclosure

[anonymous]

URL:
  

 Summary: Account Registration page information disclosure
   Group: Savannah Administration
   Submitter: None
   Submitted: Thu 18 Jul 2024 08:14:21 AM UTC
Category: Savannah website
Priority: 5 - Normal
Severity: 6 - Security
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: d...@20i.com
Operating System: None
 Open/Closed: Open
 Discussion Lock: Any


___

Follow-up Comments:


---
Date: Thu 18 Jul 2024 08:14:21 AM UTC By: Anonymous
Hi,
I hope you are doing well.

I am trying to register an account on
https://savannah.gnu.org/account/register.php I am getting an error showing
the raw SQL query.

This could be used as an attack vector for SQL Injection attacks.
I am attaching a screenshot, the name is GNU-Savannah-registration-page.png.

Due to the SQL error described above new user registration is not working. 
Would you please look into this issue too?
Thank you.

Best regards,
Dimitar Nikov






___
File Attachments:


---
Name: GNU-Savannah-registration-page.png  Size: 28KiB


AGPL NOTICE

These attachments are served by Savane. You can download the corresponding
source code of Savane at
https://git.savannah.nongnu.org/cgit/administration/savane.git/snapshot/savane-b921eb6f47f98f9b46802ed414f7b7f6c3798603.tar.gz

___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.nongnu.org/


signature.asc
Description: PGP signature

[sr #111091] Need to reset mediagoblin "master" branch to match "fixed-master" branch

[Bob Proulx]

Update of sr #111091 (group administration):

  Status:None => Done   
 Assigned to:None => rwp
 Open/Closed:Open => Closed 

___

Follow-up Comment #3:

I rolled master back to 9c9b7ea0 which is in the ancestor path to 65fa2973 so
you should be able to pull it forward to 65fa2973 yourself now. Rolling back
to 9c9b7ea0 is the easier path for me.  This converges us in the middle and
should resolve the problem for you easily.

Thank you for double checking that you were logged in and posting as you. 
Couldn't take that action from an anonymous account.  So I appreciate the help
there.

If that does not resolve things completely for you then please let us know. 



___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.nongnu.org/


signature.asc
Description: PGP signature

[sr #111091] Need to reset mediagoblin "master" branch to match "fixed-master" branch

[Bob Proulx]

Follow-up Comment #4, sr #111091 (group administration):

I wanted to also say sorry for the delay. Things have been busy. In the future
you can poke us to get moving by sending email to savannah-hackers-public AT
gnu.org mailing list.



___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.nongnu.org/


signature.asc
Description: PGP signature

[sr #111093] Account Registration page information disclosure

[Bob Proulx]

Update of sr #111093 (group administration):

Priority:  5 - Normal => 9 - Immediate  
Severity:6 - Security => 5 - Blocker
  Status:None => Done   
 Assigned to:None => rwp
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

Thank you for reporting this problem.  It is most appreciated.

There was an out-of-sync case between the web site PHP and the database scheme
for one of the fields.  It was requiring a field to be present that has not
previously been required.  I modified the database schema to match.

I believe this fixes the problem.  Please try registering the account again. 
Thank you again for your problem report!



___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.nongnu.org/


signature.asc
Description: PGP signature

[sr #111093] Account Registration page information disclosure

[Bob Proulx]

Follow-up Comment #2, sr #111093 (group administration):

BTW... I wondered why the ticket was marked disclosure.  Then I realized that
it is showing to you the information that you input.  That is not a public
disclosure. It is the data you input being returned to you. It is not
disclosed to any other party. And one assumes you input it so you already know
what you input.

It was good of you to redact the password hash from your image upload.
Otherwise that would have been a disclosure.  Even though it is hashed.

I don't trust image tools to do the right thing in all cases.  Instead of
redacting it as an image I would have copied the text into the report. The
text is almost always better anyway. Then it can be searched for and indexed
for example. And then redacting from the text is definitely going to be
redacted.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.nongnu.org/


signature.asc
Description: PGP signature

[sr #111092] Can't create an account on Savannah.gnu.org - SQL error

[Bob Proulx]

Update of sr #111092 (group administration):

Category:None => Savannah website   
Priority:  5 - Normal => 9 - Immediate  
Severity:  3 - Normal => 5 - Blocker
  Status:None => Done   
 Assigned to:None => rwp
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

Thank you for reporting this problem.  It is most appreciated.  I am very
sorry this caused you so much frustration.

There was an out-of-sync case between the web site PHP and the database scheme
for one of the fields.  It was requiring a field to be present that has not
previously been required.  I modified the database schema to match.

This occurred because we upgraded the database system to the latest version.
Which upgraded the MariaDB database software. Which brought forward more
strictness in checking conditions. This condition has been in the system
probably since the introduction of that field. Decades maybe. Years
certainly.

I believe modifying the table schema this fixes the problem. I reproduced the
problem, then modified the schema, then tested and I was able to register a
new account fully.  Seems to be okay.  Please try registering the account
again.  Thank you again for your problem report!

Note that I have one more database upgrade in the queue for today. During that
time I will need to take the registration page offline again during that time
period. I will try to keep that short. I update the status on the maintenance
page when I do it so that users are informed of the status.



___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.nongnu.org/


signature.asc
Description: PGP signature

Re: [sr #111092] Can't create an account on Savannah.gnu.org - SQL error

[Bob Proulx]

Jing Luo wrote:
> To Bob: I mentioned many months ago that some SQL errors (including but
> maybe not limited to STRICT_TRANS_TABLES being on by default) would happen
> because of the newer version of MariaDB, which I tested based on Savane 3.12
> and MariaDB 10.11. I was unable to fix those at the time. Then I forgot to
> remind you of it when the migration happened.

I am sure you did warn about this.  Unfortunately I have slept since
then and forgotten those details.

Thank you for alerting me to the problem on IRC this morning so that
we could get this fixed for the users soonest!  That was great!

> --8<-cut-here--8<---
> db_query: SQL query error in [ INSERT INTO `user` (`user_name`, `user_pw`,
> `status`, `realname`, `email`, `add_date`, `confirm_hash`) VALUES
> ('jingbot', '$y$salt$blob', 'P', 'jingbot', 'fakeemail@jing.rocks',
> 1721274927, 'deadbeef')] Field 'people_resume' doesn't have a default
> value
> --8<-cut-here--8<---
>
> A temporary workaround would to to disable STRICT_TRANS_TABLES globally.

The root cause of the exception is this:

> Field 'people_resume' doesn't have a default value

Here is the important parts from the table schema.

MariaDB [savane]> show columns from user;

+---+--+--+-+-++
| Field | Type | Null | Key | Default | Extra   
   |

+---+--+--+-+-++
| user_id   | int(11)  | NO   | PRI | NULL| 
auto_increment |
| user_name | varchar(33)  | NO   | MUL | NULL| 
   |
...
| people_resume | text | NO   | | NULL| 
   |

The Null column indicates that people_resume cannot be NULL.  The
Default value is NULL.  It must have a value supplied for it.

It appears that previous versions of MySQL ignored this condition.
Because certainly the PHP code as indicated above has not ever set
that column to a non-null value.  This seems to be a bug that has been
hanging around for a long time.  I think MariaDB is justified in
throwing the exception for this error case.

To fix this I removed the requirement that the field be non-null.
It's nice if people fill in something there.  Tell us a little
something about yourself!  But it has not been required.  Therefore
the table schema requiring it is out of sync with our practice.

MariaDB [savane]> ALTER TABLE user MODIFY people_resume text;
Query OK, 0 rows affected (9.317 sec)
Records: 0  Duplicates: 0  Warnings: 0

[[ I initially tried it on the standby system on the now throwaway
copy of the database.  I used a slightly different syntax.  And had a
completely different result!

MariaDB [savane]> ALTER TABLE user MODIFY people_resume text NULL;
Query OK, 27351 rows affected (1.469 sec)
Records: 27351  Duplicates: 0  Warnings: 0

That felt pretty scary!  I was glad I had the non-critical discardable
spare around for this test.  I researched the syntax a little more and
allowing null being the default I changed to the other syntax above
and that avoided the updating 27351 which did not need to be updated.
And not sure exactly what it did, I think it simply "updated" the row
without actually doing anything, as I could not detect a problem
afterward.  It's good to have a development system for testing. ]]

> (I don't quite understand what the requester meant by "direct messages" and
> "propagate amongst the different servers".)

I think they meant email.  I think they meant there was no way to send
an email to the person they wanted to contact.  That the only way to
make contact was to submit a ticket to them through Savannah's ticket
tracker.  They did not say what project they are wanting to submit a
ticket to and therefore I don't know either.  But I presume that
unnamed project has no email for them and no mailing list either.

And then they are under the impression that the Puszcza instance of
the savane software is federated with Savannah.  That's not the case.

Thanks again for the help in getting this problem resolved quickly!

Note that there is one more database action in the queue for today.
Having upgraded the internal1 database server to the current Trisquel
and MariaDB I am migrating the database back from internal2 over to
internal1 again.  It's been happy there for many years.  This couples
it more tightly to the git server which is very busy.  internal1 has
twice the memory and cpus allocated compared to internal2.  And then
we will be up to date until the next version of Trisquel releases.

Bob

[sr #111092] Can't create an account on Savannah.gnu.org - SQL error

[Bob Proulx]

Follow-up Comment #2, sr #111092 (group administration):

I also see now that you mention Puszcza and think it might be federated with
Savannah. Puszcza is a completely independent instance and unrelated to
Savannah. The connection is that Puszcza is running the same underlying
"savane" free software forge code. Nothing beyond that is shared between the
two sites.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.nongnu.org/


signature.asc
Description: PGP signature

[sr #111091] Need to reset mediagoblin "master" branch to match "fixed-master" branch

[Ben Sturmfels]

Follow-up Comment #5, sr #111091 (group administration):

Thanks very much Bob, I really appreciate your help! I've updated that
repository and we're now back in sync.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.nongnu.org/


signature.asc
Description: PGP signature

[sr #111091] Need to reset mediagoblin "master" branch to match "fixed-master" branch

[Bob Proulx]

Follow-up Comment #6, sr #111091 (group administration):

Excellent!  Thanks for letting us know. :-)



___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.nongnu.org/


signature.asc
Description: PGP signature