GREE's Vulnerability Disclosure Announcement
Regarding GREE's Security Updates
In order to protect our customers, GREE will not disclose security issues until investigations are completed
and comprehensive patches or release versions are ready. This announcement outlines information about
recently patched vulnerabilities, along with their impact scope and the corresponding remedies.
If you believe you have identified security or privacy vulnerabilities in GREE products, please directly
send security issues to: iotsecurity@cn.gree.com
For the vulnerabilities you submit, the corporate reviewer will try to complete the confirmation within 3
business days. Security updates for "critical security issues" will be released within 7 business days,
while security updates for software-related "high-risk security issues" and "medium-risk security issues"
will be released within 30 business days. Security updates for security vulnerabilities concerning firmware
and hardware of smart products will be released within 180 business days. Please refer to the GREESRC
Vulnerability Remediation Process and Grade Rating Criteria for vulnerability grading criteria.
Obtain the latest software update from GREE:
Download the link for the latest app version:
http://global.ewpeinfo.com/GreePlusInternational/
Please update your application promptly, as this is one of the most crucial steps in
maintaining the security of GREE products.
Vulnerability Grade Rating Criteria
The vulnerability grading criteria are based on CVSS v3 (Common Vulnerability Scoring System), and
vulnerabilities are categorized into five grades, namely [Critical], [High-risk], [Medium-risk], [Low-risk],
and [No Impact], according to the impact of vulnerabilities on system confidentiality (C), integrity (I),
and availability (A).
Critical
1. Vulnerabilities that can directly access core system privileges (server/client
permissions), including but not limited to uploading Web Shells, arbitrary code execution, remote command
execution, SQL injection to access core system privileges, etc.;
2. Critical information leakage vulnerabilities in the core system, including but not limited to SQL
injection in core DB, extensive sensitive user identity information leakage (at least 3 sensitive fields:
name/ID card, bank card information, phone number/email, passwords, address), internal core data leakage of
enterprises, etc.;
3. Critical defects in the logical design or process of the core system, including but not
limited to payment vulnerabilities allowing bulk modification of any account passwords, arbitrary account
fund consumption, arbitrary amount modification, etc.;
4. Vulnerabilities critically impacting the availability of the core system,
such as vulnerabilities of denial of service that can directly cause paralysis of core system business;
High-risk
1. Vulnerabilities that can directly access important business system privileges
(server/client permissions), including but not limited to arbitrary command execution, uploading Web Shells,
arbitrary code execution, SQL injection to access core system privileges, etc.;
2. Vulnerabilities directly leading to the leakage of important information, including but
not limited to SQL injection vulnerabilities in important DBs; leakage of extensive important business
source codes; and SSRF vulnerabilities that enable access to internal networks and access sensitive
information.
3. Critical unauthorized access, including but not limited to bypassing
authentication to access important system backends; and operations such as unauthorized access,
modification, and deletion of sensitive user information.
Medium-risk
1. Vulnerabilities requiring interaction to access user identity information, including but
not limited to stored XSS vulnerabilities in core and important systems; and CSRF for sensitive operations
(payment, account information, etc.);
2. Arbitrary file operation vulnerabilities, including but not limited to arbitrary file
reading, writing, deletion, uploading, downloading, etc.;
3. Ordinary unauthorized access, including but not limited to bypassing restrictions to
modify user profiles, perform user operations, read user information; and bypassing restrictions to access
non-core business system backends;
4. Moderately critical information leakage vulnerabilities, including but not limited to SQL injection and
unauthorized access not involving important data; limited-range sensitive file leakage (e.g., DB connection
passwords) and weak passwords for accounts (e.g., regular users, test users).
Low-risk
1. Reflective XSS; and non-critical system stored XSS;
2. Limited-harm unauthorized operations (e.g., unauthorized emptying/adding to cart);
3. Minor information leakage, including but not limited to Phpinfo; non-core system SVN
information leakage; non-important information leakage (e.g., unusable DB connection passwords); and local
SQL injection in client applications;
4. Vulnerabilities that are difficult to exploit but pose security risks, including but
not limited to difficult-to-exploit SQL injection points; local denial of service in clients; and
vulnerabilities under specific conditions or environments (e.g., SMS, email bomb, URL redirection);
5. Vulnerabilities that pose security risks but require extremely stringent
conditions for exploitation, including but not limited to vulnerabilities only triggered on a specific
version of a browser, and vulnerabilities requiring special configurations to trigger.
No Impact
1. Vulnerabilities not related to security issues, including but not limited to defects in
website product functionality, garbled pages, mixed styles, URL skip at login, etc.
2. Vulnerabilities that cannot be exploited, replicated, or result in actual harm.
3. Other issues that have no impact on GREE's business.
Other issues not categorized within specific types will be comprehensively evaluated based
on their actual harm and CVSS.
Vulnerability Remediation Process
GREESRC Vulnerability Remediation Process is as follows:
1.[Vulnerability Submitting]
The white hat logs in to the Butian account and submits vulnerability
reports. Once a vulnerability is submitted, it cannot be edited or modified. Please ensure the accuracy of
the vulnerability information before submitting it. After successful submission, the vulnerability status
will be displayed as [Under Review].
2. [Vulnerability Review]
The corporate reviewer will conduct a preliminary review of the vulnerabilities within 3 business days (the
review speed may slow down during statutory holidays or in the event of a vulnerability outbreak).
Vulnerabilities that do not pass the preliminary review will be ignored or requested to provide additional
information. White hats can supplement the information or engage in discussions below the vulnerability. If
there are repeated vulnerabilities within the same time period, only the first complete report will be
considered. For repeated vulnerabilities in different time periods, the first submission will be considered.
Vulnerabilities that pass this stage will be displayed as [Pending Confirmation] in the status.
3.[Vulnerabilities Confirmation]
The corporate reviewer will confirm the vulnerabilities within 7 business days (extended during statutory
holidays), and white hats will receive corresponding rewards once the vulnerabilities are confirmed. If
there are any disputes regarding the confirmation level, a vulnerability appeal can be initiated within a
validity period of 3 days, and the Butian platform will intervene and negotiate the resolution. During this
stage, the status of the vulnerabilities will be displayed as [Pending Remediation].
4.[Vulnerability Remediation]
Vulnerability Remediation Platform: https://www.butian.net/Company/1100
Remediation Process:
（(1) The asset owner receives a vulnerability notification email and simply needs to click on the
vulnerability link in the email to be redirected to the vulnerability detail page for review. If not
registered, after registering an account, the asset owner can review the number of vulnerabilities and
detailed reports corresponding to the vulnerability status in the [My Vulnerability Management] menu.
(2) After reviewing the vulnerability report, the asset owner needs to click on the [Please Confirm
Acknowledgment of the Vulnerability] button at the top or bottom of the vulnerability report page. Upon
clicking, the vulnerability status will change from "New Notification" to "In Remediation". If the "Please
Confirm Acknowledgment of the Vulnerability" button is not clicked, the vulnerability status will remain as
"New Notification". The platform will send new vulnerability reminder emails to the relevant personnel every
business day at 9:30 a.m.
(3) After remediating the vulnerability, the asset owner can open the [In Remediation] vulnerability report
in [My Vulnerability Management] and then click on the [Apply for Retesting] button to access the
application for the retesting page. After filling in the remediation method, the asset owner can submit the
retesting application. The platform will automatically send a vulnerability retesting request email to the
security personnel, and the vulnerability status will change to [Retesting in Progress]. If the asset owner
is aware of the vulnerability but decides not to remediate it, they need to submit the "Vulnerability Risk
Acceptance" process on the review platform. After the information security officer agrees to not remediate
the vulnerability, the vulnerability remediation process is concluded.
(4) After receiving the retesting notification email, the security personnel retest the vulnerability. Once
the retesting is completed, they can click on the [Submit Retesting Results] button on the platform to
access the retesting result submission page. After the security personnel have completed the retesting, the
platform will automatically send an email to inform the asset owner whether the vulnerability remediation
has been verified. If it is verified, the vulnerability status will change to [Completed]. If it is not
verified, the vulnerability status will change to [In Remediation]. The asset owner can continue with the
remediation process and apply for retesting again.
5. [Vulnerability Closed]
The enterprises confirm vulnerability remediation completion and close the vulnerability.
Vulnerability remediation process is complete.
DECLARATIONS:
To submit a GREESRC vulnerability, white hats must accept the Butian User Service Agreement and observe the
White Hat Code of Conduct. Without the manufacturer's permission, it is strictly prohibited to publicly
disclose any vulnerabilities submitted to GREESRC (including ignored vulnerabilities). Violators will have
their awarded rewards deducted and shall be subject to legal consequences depending on the severity of the
situation.
