Blog

An Interview with Xcalibyte’s Chief Scientist, Long Li

In recent years, with the rise of artificial intelligence and IoT devices, our lives have been inundated by a variety of “smart” and “automated” services, with a large amount of software development being done to provide them. one of the biggest problems is that the quality of the software lags behind what markets expect, often leading to security issues. Studies show that 82% of all security vulnerabilities lie within the application source code (Forrester). On average, there is one issue in every 1,000 lines of code and one high-risk issue in every 1,400 lines of code.

Xcalscan was developed to confront such a challenging situation. Dr Long Li, the Chief Scientist of Xcalibyte, discusses some of the key points that he talked about in his recent speech at the CPP-Summit 2020. The topic was “A Tool for Verifying Business Logic beyond Common Vulnerabilities”.

Question 1: You talked about “Verifying Business Logic” at the CPP-Summit in Shenzhen last year. Can you tell us what you mean when you say ’business logic’?

Business logic, sometimes known as domain logic, takes the real-world business requirements and then determines how the functions and features of the program are created to fulfil them. There are many small functional modules and features that are programmed and they have to be integrated to create the overall business logic. The business logic exists at a higher level than the type of code that is used to maintain basic computer infrastructure.

Question 2: Why do vulnerabilities occur from business logic and can you give us some examples?

Firstly, vulnerabilities in software often originate from defects or deviations in design or implementation. For software to be developed, if the real-world description (natural language) of the function is not written down precisely, the development team will experience difficulties in sub-module implementation, thus affecting the core function. However, in design and implementation, no matter how clearly the description is written, the translation from natural language into the programming language will inevitably create minor errors. This is common and this is also how bugs often occur.

Secondly, the development of a complex software application usually involves multiple teams. As tasks are assigned to different teams, developers may not fully understand the function holistically thus affecting the implementation. If the interfaces of different modules are not clear enough or there are deviations in implementation, the entire program may run into problems. When the software functions are changed or enhanced, the modification to the original functions and the involvement by new developers, make bad situations more likely to occur.

Further, developers’ misunderstanding of third-party or library functions is also a source of introducing software vulnerabilities. Chrome’s ZERO day vulnerability, CVE-2019-5786, is caused by the developer’s improper use of std::move(). The enthusiasm to use the latest standards or interfaces is widespread amongst software developers, but they need to invest their time to learn and understand them properly before they actually use these new things. Moreover, not all of the new standards or interfaces are reasonable, such as std::move() mentioned here. Its function can be achieved automatically in a compiler’s optimization process. Providing an interface that asks all developers to try to complete the task that a compiler’s optimization fails to, provides a source that may lead to a large number of vulnerabilities.

Question 3: How do we find errors in business logic? What practices do you use?

We use a code analysis tool, Xcalscan, to scan the software. If only the software’s main functions are required to be verified, it is not time-consuming. For example, if we only need to check the code developed by the software team and not third-party libraries. Simply put, this is a process of converting the natural language description into the detection parameters that the scanning tool can recognize. To verify these vulnerabilities, we can do the following.

Initially, we provide interfaces that the scan tool can recognize to allow users to map software functions, namely business logic, described in natural language into programming language. For example, if I write using the C programming language, and I have a natural language description for it, then I can map them together to allow Xcalscan to determine if my implementation matches the description automatically.

We also use a mathematical computation model known as Finite-State Machine (FSM). It is an abstract machine that stores a sequence of different unique states to represent and control flow inside the program. In verification practice, FSM determines what to do first (input), and then what the outcomes (output) are, which defines the current state. The translation from natural language description of business logic to a strict mathematical definition may be mismatching and/ or incomplete, another reason for vulnerabilities.

‘Shifting-left’ for security testing is now commonly advocated for in software development, so that issues can be found in the earlier stages thus lowering the high remediation costs associated with finding bugs in later stages. The software development life cycle includes design, implementation, testing, and delivery. The labour and time cost of repairing errors that are exposed only when the user starts to use them in production (late stage) is the highest, which far exceeds the cost of discovering and repairing at the time of development (early). Early stage defect and vulnerability detection is more commonly being viewed as critical in the SDLC where a developer must adopt a quality first and security by design mentality.

Question 4: What will happen if business logic is not thoroughly verified?

Business logic enforces the real-world rules and constraints whilst designing and developing your software. A very big problem is when a function deviates from the business logic. When this happens, a developer might add to the missing components to deliver upon the business logic. But, creating too many new functions that were not carefully considered in the design stage, can lead to fatal vulnerabilities such as exposing sensitive data. The security implications of this are very clear.

If a software’s business logic cannot be verified and it is delivered without proper approvals, the delivered code will provide an entrance to private data for malicious attacks, which will lead to serious business consequences. As an example of what can happen, late last year in Singapore, hackers exploited vulnerabilities in home cameras and accessed 50,000 of them. Private footage taken from these cameras were then uploaded to the Internet. The business logic failure was most likely due to the developers not mapping out the user scenarios carefully and failing to account for weak passwords.

Question 5: How can Xcalscan help in verifying business logic?

Besides detecting errors in the early stages of the SDLC to proactively address security concerns and thus lower remediation costs, Xcalscan can help users to verify functions described in natural language descriptions in the implementation with the corresponding programming language.

We receive many requirements from our customers for their specific business logic to be verified, as they have found it hard to find tools that can be customized to their needs. This is what Xcalscan was designed for. Xcalscan provides customizable rules, so that customers can express their specific business logic which can be applied to static code analysis. This is the customization advantage of Xcalscan.

Question 6: Regarding “verification of business logic “, what is the difference between traditional formal verification and Xcalscan’s formal verification?

Formalizing business logic into mathematical representation is non-trivial and hard for many to understand. First, it requires well-trained people, with strong mathematical skills and an understanding of business logic processes. Analyzing code is not just a way of identifying syntax errors and correcting them. It needs to go much deeper than that.

Second, when natural language descriptions change mid-project, the programming changes that have to be made require manual verification which can be inefficient and time-consuming. In practice, using traditional formal methods, verifying one line of programming code requires 17 lines of mathematical proving code.

Xcalscan’s accuracy in identifying issues is on par with traditional formal methods. However, utilizing Xcalscan is better in efficiency and adoptability. It can visually help users understand and recognize the deviations in their software development.

According to our experience, 80% of customers’ customization requirements can be achieved by customers themselves via limited interfaces provided by the scan engine, while the other 20% would need our professional services to help out. Our current customers include Horizon Technologies, Uisee, and Hisense Juhaolian.

You can download the full presentation for ‘A Tool for Verifying Business Logic beyond Common Vulnerabilities’ here.

Dr. Li is a senior member of the Xcalibyte core technology team, focusing on Rule-Based-Checker infrastructure and standard coding rule conformance including CERT and OWASP.