Tue, May 07 2019 00:10:45 +0000 Script: /libs/html.inc.php - Line: 413 REPLACE INTO ubbt_ONLINE (USER_ID,ONLINE_DISPLAY_NAME,ONLINE_LAST_ACTIVITY,ONLINE_SCRIPT_NAME,ONLINE_BROWSING_FORUM,ONLINE_USER_TYPE,ONLINE_USER_IP,ONLINE_REFERER,ONLINE_AGENT,ONLINE_POST_ID,ONLINE_POST_SUBJECT) VALUES ( 1 , '-ANON-42.77.245.9' , 1557182581 , 'portal' , '' , 'a' , '42.77.245.9' , 'http://m.facebook.com' , 'Mozilla/5.0 (iPhone; CPU iPhone OS 12_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/15E148 [FBAN/FBIOS;FBDV/iPhone9,4;FBMD/iPhone;FBSN/iOS;FBSV/12.2;FBSS/3;FBCR/中-華-電-信-;FBID/phone;FBLC/zh_TW;FBOP' , 0 , '' ) - Data too long for column 'ONLINE_AGENT' at row 1
Mozilla/5.0 (iPhone; CPU iPhone OS 12_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/15E148 [FBAN/FBIOS;FBDV/iPhone9,4;FBMD/iPhone;FBSN/iOS;FBSV/12.2;FBSS/3;FBCR/中-華-電-信-;FBID/phone;FBLC/zh_TW;FBOP
WOW! - My god, thats a lot of additional garbage. IMHO, stuff that has no business being in the user agent header. A lot of garbage in that user agent. The useful stuff is towards the beginning.
HTTP specification does not limit length of headers at all.
However web-servers do limit header size they accept, throwing 413 Entity Too Large if it exceeds.
Since I did not write that script and haven't revisited it for anything other than page presentation and to parse IPv6 vars, I will take a peek in to it again and see how large the database field allows, and truncate anything to just before that value. Im going to take a wile guess and assume that its set to 200 chars. Your posted UA example is 257 chars.
thank you.
Last edited by isaac; 05/07/20193:26 AM. Reason: clarity. spelling. add links.
It is 1am as I am replying, and this topic of dealing with multi-byte character sets (such as Chinese uses) is not fluent to me, but I must ask -- Are using a UTF-16 or a UTF-8 Unicode set for your database? With UTF-16, every char is encoded into 2 or more bytes than UTF-8.
Your 255 substr() would now have 257 chars. This could happen when a multi-byte character gets cut in half. I'm going to assume that the UA you posted, did include Chinese characters within it.
If this is the case, you may want replace the "substr" functions with "mb_substr" (there are two of them), and add the internal encoding (UTF-8) as exampled below:
I want to recommend it to more people... but UBB.threads in Chinese more problems to fix... So work with you... thank you!! thank you!!
Server Information UBB Version 7.7.1 Server Type Linux Server Load 0.00 Web Server nginx/1.10.3 PHP Version 7.2.5-1+0~20180505045740.21+stretch~1.gbpca2fa6 MySQL Version 10.2.14-MariaDB-10.2.14+maria~stretch-log Server connection utfmb4 Database Collation: utf8mb4_unicode_ci
Fatal error: Uncaught ArgumentCountError: Too few arguments to function Admin::setParentTitle(), 1 passed in \admin\edit_subscription.php on line 88 and exactly 2 expected in \libs\admin.inc.php:126 Stack trace: #0 \admin\edit_subscription.php(88): Admin->setParentTitle(NULL) #1 {main} thrown in \libs\admin.inc.php on line 126
I have never seen this many errors from anyone. And I have been here a long time with many versions over the years.. The current version seems to be the most error free for a install..
Could it be you need to start over with the install.
Then follow the install directions exactly.: https://www.ubbcentral.com/doc_install.php Following all the file /folder permissions. Some hosts don't allow 777 so if that is true try 775
Plus read the readme file in the downloaded zip file from the members area.
The default character set is utf8 set in the generic.php language file on line 2. In almost all cases you would create a new database using utf8 if not the you need to edit the language file to match.
Blue Man Group There is no such thing as stupid questions. Just stupid answers
From what I understand, you've modified your database to use utf8mb4_unicode_ci rather than a latin based utf8_general_ci or latin1_swedish_ci collation; which from what I'm seeing is causing you a huge amount of errors because UBB.threads doesn't know how to work with the data you are presenting to it (please, stop making new posts for every new MySQL error as they all stem from the same issue and can be amended to the same thread).
UBB.threads is a software product from the mid-90's that's been ported up through standards through the years, and is long older than the UTF8 became the web standard; hence why it does not fully support 4-byte utf8 unicode such as what current digital Chinese or Japanese characters use, at this point.
We understand that English isn't your first language, and you don't fully understand it; but some of your bug reports are so vague and hard to follow that we're unsure of what the ultimate problem is, let alone how to reproduce the errors that you're getting.
You're attempting to insert a multi byte character into a single byte slot; as mentioned above, this software has never been tested before for UTF8MB4 and assumes you're using a Latin based collation. Modifying the software to preform on this collation just won't have the desired behavior you're looking for.
You're getting all these errors because you have modified the stock code from expecting the use of a 3-Byte UTF-8 Unicode Encoding character set, to utf8mb4 a 4-Byte UTF-8 Unicode Encoding character set.
UBB.threads currently does not provide support for supplementary character sets (ie; Chinese, Japanese). UBB.threads currently only provides support for Basic Multilingual Plane (BMP) characters.
edit: Very recently (2015 to now) UBB.threads base code has been getting many modern updates since its initial release in the 90s, but it still requires additional coding to support utf8mb4, as you're now finding out This may come eventually, but there are many other updates ahead of that.
It would appear that there are two IP addresses trying to be inserted, which exceeds the length of the cell in the database; we really need you to fill out complete error logs, along with your URL, any modifications you've installed, and how we can replicate the error...
Note that NO modifications to the base software are supported, and this includes modifying your database and mysqli.inc.php file to run utf8mb4, as the software just doesn't support it at this time.
Any "data too long" errors are directly related to your attempt to insert a multibyte (utf8mb4) string where a single byte (utf8) is expected (as it takes up more space that what is anticipated).
Please stop posting issues directly related to your unsupported usage of utf8mb4; we're not just going to magically be able to make it work with the wave of a wand, it'd take a significant amount of time which we're already using for further PHP7.2+ updates.
You might even need to File a Support Ticket with the vendor (we're here simply volunteering our time) so that your hosting environment and forum files can be checked.
the % is stopping the very basic AutoURL processor, which doesn't work with % (which are the codes for his local language). this isn't a showstopper as the BBCode can process it just fine.
If you look at your highlighted text you can see what is happening, your server is relaying three values for IPs and the string they make is too long for the field; a future build should split the IPs into the correct length (by only using one). FYI, 606.249.802.090 is an invalid IP address.
In my near-20 years of working with UBB.threads software, I've never seen anything like what you've posted.
This has brought me to perform a few Google searches for elements within your post.
What was returned goes back to 2015 with an attacker attempting to perform a POP chain exploit to Joomla CMS.
Quote
[the] request headers must contain malicious data known as a "POP Chain" (Property Oriented Programming). POP chains, similar to their older cousin ROP (Return Oriented Programming) are constructed of a series of “magic PHP methods†that already exist in the code, which is why these kinds of attacks are often referred to as code reuse. An attacker must link these methods together in order to achieve their desired code execution.
The POP chain is then sent from the attacker in either the User-Agent or X-Forwarded-For header, the attacker saves the session cookie that is returned upon completion of the request. From what we have noticed, most of these POP chains run eval() on the POST data, but not all of them, as you can also run a chr() encoded string into eval() that will execute all the bad PHP calls: system(), popen(), exec(), passthru(), shell_exec(), etc. Here is an example of part of the exploit payload:
Although there is already IP address sanitation built in to current and prior versions of UBB.threads, there has been further IP address sanitation built in for version 7.7.2, but as you've posted earlier, you increased the size of your user IP address storage table from VARCHAR(46) to VARCHAR(111), which may potentially cause issues in key locations of the UBB.threads software, and could also cause security related issues due to the you now allowing more non-IP address data to be stored an IP address table. We have not instructed that you do that.
If non-IP address are attempting the be written in to an IP-address-only field, its best to deal with whats allowing that, rather than to just accept it what the attacker wants to do and making him feel welcomed by increasing the field size for him. :/
Last edited by isaac; 06/08/20191:29 AM. Reason: added more content