Hot search keywords

Hot search keywords

Blockchain software security report by China CERT, Ripple the worst

In December 2016, China CERT released a 17-page security audit report of blockchain software. As per the report, the audit was conducted in October 2016 and released later as “open” document. The report examined 25 open-source blockchain projects, categorizing the vulnerabilities found into 9 classes. A total of 746 high-level attack vectors are detected. Ripple is rated the most insecure one with over 223 highly risky bugs.

warning sign focused in loupe and programming code background.

China CERT,  the National Computer Network Emergency Response Technical Team/Coordination Center of China (known as CNCERT or CNCERT/CC) , was founded in September 2002. It is a non-governmental non-profit cybersecurity technical center and the key coordination team for China’s cybersecurity emergency response community. The CERT lab speaks highly of the global development around blockchain technology but also reiterates the importance of blockchain software security.

“Any vulnerability may result in huge property loss”.

The statistics in the report comes from scanner tools and manual review. The report only analyzes vulnerabilities from a coding perspective. Due to the restriction of the deployment environment and security equipment, some of the vulnerabilities may not be verified via penetration test.

 

Overview of 25 projects being audited
Based on the number of user group, followers and commit frequency, the CERT lab selected 25 blockchain with well-known reputation and extensive community both at home and abroad. These software were written with C, C + +, Java, Python, PHP and other programming languages.
Below is the overview of projects being reviewed:

blockchain-project-overview

Table 1: Overview of 25 blockchain projects

9 vulnerability categories
This test covers a variety of commonly seen security vulnerabilities, which are divided into 9 categories by the following criteria: formation cause of security vulnerabilities, the possibility of being exploited, the degree of harm and the difficulty to solve.

1. Input Validation and Representation
Input validation and representation problems are usually caused by special characters, encodings, and numerical representations. Such problems occur as a result of input trust. These problems include: buffer overflow, cross-site scripting, SQL injection, command injection and so on.
2. API Abuse
The API is a convention between the caller and the callee, and most API abuses are caused by the caller not understanding the purpose of the convention. Security problems can also arise when the API is not used properly.
3. Security Features
This category contains vulnerabilities in authentication, access control, confidentiality, password usage, and privilege management.
4. Memory Management
Memory management is a common type of vulnerability associated with memory operations, including memory leaks, post-release use, double-release and so on. This type of vulnerability usually leads to system performance degradation, program crashes and a common type of flaws in C / C + + language.
5. Time and State
Distributed computing is time and state dependent. The interaction between threads and processes and the order in which tasks are executed are often determined by shared state, such as semaphores, variables, file systems and so on. The vulnerabilities associated with distributed computing include race conditions, blocking misuse and so on.
6. Error and Exception Handling Errors
This type of vulnerability is related to error and exception handling, and the most common type of vulnerability is that there is no proper processing mechanism (or errors are not processed), resulting in unexpected termination of program. Another vulnerability is that the error generated provides potential attacker with too much information.
7. Code Quality
Poor code quality can lead to unpredictable behavior. For the attacker, the poor code enables them to threaten the system in unexpected ways. Common types of vulnerabilities include dead code, null pointer dereferences and resource leak.
8. Encapsulation and hidden defects
Reasonable encapsulation means that the distinction between verified and unverified data, distinction between data of different users, or distinguish data that is visible or invisible to users. Common vulnerabilities include hidden fields, information leakage, cross-site request forgery and so on.
9. Flaws in Code Runtime Environment
These types of vulnerability is external to the source code, such as runtime configuration issues, sensitive information management issues and so on, which are critical to the product security.

The first eight types of vulnerabilities are related to security flaws in the source code. They can be the target of malicious attacks. Once exploited, they can cause serious consequences such as information leak, authorization lift and command execution. The last type of vulnerability describes security concerns that are external to the actual code. They are likely to cause abnormal operation of the software, data loss and other serious problems.

Rating of vulnerability 

The lab classified the source code security issues into three levels: High, Medium, and Low. Criteria for measuring the level include two dimensions, confidence and severity. Confidence refers to the probability if the problem is found to be accurate. For example, strcpy () call flagged as a buffer overflow vulnerability has low confidence. Severity refers to the seriousness of a problem if the test technique is authentic. For example a buffer overflow, which is often a more serious security issue than a null pointer dereference. The combination of these two factors can be accurately classified for security issues, as shown in Figure 1.

figure-1-confidence-and-severity

 

Ripple the most insecure project
746 high-level and 3,497 medium-level bugs were detected among the 25 projects with Ripple taking the lead by 223 highly risky loopholes. Figure 2 shows the statistics of high and medium level security vulnerabilities detected in the 25 projects. The red line indicates the number of vulnerabilities per thousand lines of code (total number of bugs / code lines * 1000)

fig2-high-level-vulnerability-allocation

Figure 2 Statistics of vulnerabilities detected in 25 projects

“It is noteworthy that among all the projected being audited this time, Ripple is likely to be the most widely used one with the most users. At the time of writing, the software company has received 100 million USD investments from Google and Accenture. Some large financial institutions have announced their joining the payment network, including Standard Chartered, Westpac, Shanghai Huarui Bank and so on. Given the fact that Ripple is directly dealing with financial assets, should these loopholes be exploited by hackers, the institutions may suffer unimaginable losses.”

Ethereumj comes as the second most risky project with 110 high-level vulnerabilities. Bitshares contains 4 high-risk bugs and 665 medium ones, the highest number among all projects.
Ethereum Wallet, Hlp-candidate and OmniJ are found bearing zero or only one high-level bugs and therefore considered the most secure projects among all units being audited.

High-level vulnerability Analysis

Most of the vulnerabilities fall into the category of “input validation and presentation”, which mainly results from the incomplete verification of user inputs. Malicious input may trigger arbitrary command execution, full access to files and other serious security issues.

figure-3-distribution-of-high-level-vulnerabilities

“For example, some Java blockchain software, like Ripple, with the JNI framework use other language such C, C++ to manipulate memory and other operating system resources, bypassing the Java memory protection mechanism, making the program vulnerable to buffer overflow attacks.”

Another category with high frequency is “Code quality issue”, which results from the “the lack of security awareness of developers” and “unstandardized coding”. Such vulnerabilities may lead to memory overflow, resource depletion and other security concerns. Worst scenario may include abnormal operation of the system or even system crash. As the blockchain software is often integrated into the operating system of financial institutions, system crash will bring intolerable losses.
“Security features” also accounts for a certain percentage of vulnerabilities, such vulnerabilities mainly cover identity authentication, authorization management, password management and other issues. Attacker can exploit the loopholes to gain unauthorized access, steal private infos. Encryption function is the core of blockchain software in maintaining the integrity of the entire whole ledger. However, according to the test results, there are a number of “unsafe random numbers” issues, which will compromise the software’s defense against encryption attacks.

JNI and random number generator vulnerabilities
Of the 25 projects tested, the two most common types of vulnerabilities are insecure JNI (16.22%, 121) and insecure random numbers (21.72%, 162).

figure-4-allocation-of-medium-and-high-vulnerabilities

Figure 4 Allocation of Medium and High Vulnerabilities (by specific categories)

1.Insecure JNI ( under the category of “input validation and representation”)
When a Java application uses JNI to call code written in another programming language, improper calling can make Java applications vulnerable to security breaches in other languages. Although there is a Java-provided memory protection mechanism, this protection mechanism does not apply to source code written in other languages and accessed through the Java Native Interface (JNI). Precautionary measure proposed is to carefully check the operation of the native language contained in the Java code and implement a rigorous input validation.

2. Insecure random number (the security feature)
In a security demanding environment, the use of a predictable value of the function as a random data source will reduce the ability of the system against encryption attacks, resulting in serious vulnerabilities like easy-to-guess password, predictable encryption keys, session hijacking attacks and DNS spoofing.
Precautions: The cryptographic pseudo random number generator should be used and the information with the largest information entropy should be used as the seed. If information entropy is not available, the threat can be reduced by changing its seed when using a cryptographic pseudo random number generator.

Medium-level Vulnerability Analysis
The medium and low risk vulnerabilities may present less risks in the real operating environment.  However, these bugs can reflect the code quality, the developer’s awareness of  security to some extent. Figure 5 shows the distribution of security vulnerabilities. Although the medium-level problems will not lead to serious security vulnerabilities, there are still pose significant threat to the system. If exploited, they may lead to serious risks like system crash. A possible cause is that some of the tests are intermediate versions that have not yet been officially released, resulting in some residue of “process code”.

figure-5-allocation-of-all-security-vulnerabilities

Figure 6 further demonstrates the allocation of various security vulnerabilities. It is noteworthy that 87 vulnerabilities with less than 10 occurrence, such as “inappropriate type conversion”, “residual debugging information” and other code quality, API-related vulnerabilities are classified as “Others” to facilitate the data presentation. The two most common vulnerabilities are unused local variables (13.94%, 1,181) and insecure string functions (13.20%, 1,118). At the end of the report, counter measures are also proposed for these two bugs.

figure-6-allocation-of-all-security-vulnerabilities

The report is the first security audit conducted by Chinese national cybersecurity institutions. The sheer number of bugs may present a setback to potential adopters.

“The 746 high-level vulnerabilities reveal that there are serious safety risks that must not be ignored.

Feedback from developers are expected to clarify the situation.

Chinese report and PDF file download.

Update: Ripple released an official response to the CERT report.

COMMENTS(69)

  • BitcoinAllBot
    1 week ago BitcoinAllBot

    Here is the link to the original comment thread. Or you can comment here to start a discussion. Author: 8btccom

  • rancymancy
    1 week ago rancymancy

    The report claims to analysis over 1 million lines of code across 8 languages and 25 projects. That’s a mammoth undertaking if you’re actually going to do it properly. Most of the projects would be so far advanced from the point they were tested by the time the report is completed that any results it turned up would likely be inapplicable anyway, and unless they specifically employed members of the projects themselves to help them understand the subtleties of the respective codebase – I can’t see how they could even do it.

    The real-world test of vulnerabilities in software is whether there’ve been exploits. Further, if there is money to be made by exploits, it’s extremely likely they will have been used. It’s possible to run analysis software with no understanding of the codebase being analysed and turn up false positives all day (what I suspect was done). Ripple has been running as a live distributed exchange and payment network for four years, and hasn’t been hacked despite almost a quarter billion dollars worth of motivation to. To me that casts significant doubt on the relevance of this report.

  • captchu
    1 week ago captchu

    That confirms my worries. Thanks for sharing.

  • OldFartWithBeard
    1 week ago OldFartWithBeard

    We need more of those! While such software audits are not the be-all-end-all they do give us a nice reality check, and comparing projects such as in this report gives me new insights.

    Seeing that this is by a CERT can we safely assume that CVE’s have been created for all these vulnerabilities? Does the Chinese text mention this?

    • OldFartWithBeard
      1 week ago OldFartWithBeard

      Well, this is turning into a disappointment…

    • Batsukh
      1 week ago Batsukh

      May I ask what’s CVE?

  • HandyNumber
    1 week ago HandyNumber

    Good link!

    I’m not sure how rigorous that report is, but that result doesn’t look good for Ripple. Were they asked for input/comment?

    Not surprised that Ethereum is high – a smart contract platform must have a much much higher attack surface than cryptocurrencies which are value-exchange only.

    I’d expect value-exchange only x-currencies such as Bitcoin to be lower.

  • lakerz690
    1 week ago lakerz690

    China is sketchy as fuck and that entire country is full of propaganda. They’ll lie about anything just to a profit from it. That being said, don’t believe anything these clowns say.

  • karalabe
    1 week ago karalabe

    Hmm, so there are two major players in Ethereum land, and they opt to audit a third implementation. Seems a bit odd 😛

  • TonyMcCarp
    1 week ago TonyMcCarp

    Ethereum Wallet, Hlp-candidate and OmniJ are found bearing zero or only one high-level bugs and therefore considered the most secure projects among all units being audited

  • CommodoreHodlor
    1 week ago CommodoreHodlor

    this is what you would call ‘signalling’. It’s a major one at that.

  • itsnotlupus
    1 week ago itsnotlupus

    Tantalizing, but stops short of interesting for me without an English version of the study.

    I don’t really care about pie charts and graphs when it comes to security problems. I care about the actual problems.

    230 high severity problems in Ripple sounds really bad, but what does it actually mean? Is not checking the length of a textfield in a native client UI considered a severe input validation bug, same as letting a network packet overflow a buffer?

    Security audits are notoriously difficult. Did they really do one on all those projects, or did they just run a generic tool and use its output?

    If this is a serious study, I hope an English translation pops up soon.

    • homakov
      1 week ago homakov

      Looks very lame visualization of automated scan. 230 high severity problems? This article is a joke.

    • 8btccom
      1 week ago 8btccom

      That’s basically the whole report. Only a little omission at the end.

  • xedd
    1 week ago xedd

    “It is noteworthy that among all the projected being audited this time, Ripple is likely to be the most widely used one with the most users. At the time of writing, the software company has received 100 million USD investments from Google and Accenture. …”
    .
    This is a surprise to me… Most widely used?

  • 3esmit
    1 week ago 3esmit

    They should have added Geth and Parity, guess they didn’t wanted to pump ethereum, so they just don’t added those. BTW, EthereumJ seems great.

  • sjoelkatz
    1 week ago sjoelkatz

    Nik Bougalis posted a response to this a few days ago: https://www.xrpchat.com/topic/2674-fud-or-legit/#comment-24048

    The short version is this: We run these same kinds of tests ourselves. Automated testing tools produce lots of false positives. Also, their reference to JNI (which has no applicability to rippled whatsoever) suggests they may have scanned repositories other than rippled that contain unsupported or experimental tools that don’t have any security implications anyway.

    • 8btccom
      1 week ago 8btccom

      Thanks for the pointer.

  • gjsteele71
    1 week ago gjsteele71

    I think the study is worthless because they did not compare enough currencies and their personal opinions played a role in the decision, but if you are bored…

  • rancymancy
    1 week ago rancymancy

    I’m really dubious of this report. Here are four reasons:

    1) The claims are too big. Accurately analysing over 1 million lines of code, in 8 different languages and 25 projects for this many vulnerabilities would be a huge undertaking. How could this have been done accurately without understanding the subtleties of each codebase? It seems highly likely they’ve used software to automate analysis – but you can run analysis software on code and turn up false-positives, errors that simply don’t apply to your use case, etc – as much as you want. Unless you’re intimately familiar with the codebase in question, it’d be difficult to configure such software to return applicable, trustworthy results.

    2) Real-world results. In the case of Ripple for instance, it’s been running as a distributed value exchange for four years, and hasn’t had one instance of hacking, or even spam attacks. In terms of real-world experience, it seems to be one of the most secure, or at the very least, demonstrably less susceptible to attack than Ethereum for example, at least in the spam category.

    3) The unclaimed prizes. Most of these projects involve value-exchange. In Ripple, there’s a quarter billion dollars worth of motivation for someone to make money out of these “223” vulnerabilities, and they expect us to believe that hasn’t happened even once?

    4) If it’s true, why not give the teams the chance to fix their code? If they truly believe their own claims, it’s tremendously irresponsible not to contact the teams involved and provide them with the details of the exploits. To my knowledge, that has not occurred. To me that makes the authors either trustworthy and also a bunch of total assholes, or just not trustworthy.

    TL;DR – some untrustworthy people have misused code analysis software to make sensationalist claims.

  • rancymancy
    1 week ago rancymancy

    I’m really dubious of this report. Here are four reasons:

    1) The claims are too big. Accurately analysing over 1 million lines of code, in 8 different languages and 25 projects for this many vulnerabilities would be a huge undertaking. How could this have been done accurately without understanding the subtleties of each codebase? It seems highly likely they’ve used software to automate analysis – but you can run analysis software on code and turn up false-positives, errors that simply don’t apply to your use case, etc – as much as you want. Unless you’re intimately familiar with the codebase in question, it’d be difficult to configure such software to return applicable, trustworthy results.

    2) Real-world results. In the case of Ripple for instance, it’s been running as a distributed value exchange for four years, and hasn’t had one instance of hacking, or even spam attacks. In terms of real-world experience, it seems to be one of the most secure, or at the very least, demonstrably less susceptible to attack than Ethereum for example, at least in the spam category.

    3) The unclaimed prizes. Most of these projects involve value-exchange. In Ripple, there’s a quarter billion dollars worth of motivation for someone to make money out of these “223” vulnerabilities, and they expect us to believe that hasn’t happened even once?

    4) If it’s true, why not give the teams the chance to fix their code? If they truly believe their own claims, it’s tremendously irresponsible not to contact the teams involved and provide them with the details of the exploits. To my knowledge, that has not occurred. To me that makes the authors either trustworthy and also a bunch of total a**holes, or just not trustworthy.

    TL;DR – some untrustworthy people have misused code analysis software to make sensationalist claims.

    • 8btccom
      1 week ago 8btccom

      Very good arguments. We will try to forward your opinion to the author.

      • rancymancy
        1 week ago rancymancy

        Thank you, I’d be interested to hear his thoughts.

        Also, David Schwartz of Ripple has just posted an official response on the Ripple website.

  • GBG-glenn
    1 week ago GBG-glenn

    ALOT of financial institutions are working with Ripple, and experementing to see if it could be used as a new type of “settlement system”. I guess one of the reasons is because it’s one of the most centralized crypto-projects out there. It could also reduce operating costs by 60%.

  • MrDuke67
    1 week ago MrDuke67

    Here you can find more info on this “affair”.

    https://www.xrpchat.com/topic/2674-fud-or-legit/

  • tommytrain
    1 week ago tommytrain

    Please qualify “most centralized”, in terms of development team and current network topology, yes, but since individual banks prefer to not share data or control with other banks on the network it can be used in an entirely decentralized manner, I.e. With privately issued tokens the way rippleConnect allows bank branches to trade internal self issued currency for inter-branch ledger reporting, balancing, and settlement.

    The “Centralized” bogeyman is a nebulous red-herring without context.

  • tommytrain
    1 week ago tommytrain

    Copy pasta of Ripple dev NikB’s response over at XRPchat:

    Just to reiterate what I wrote in the chatbox and was pasted above in convenient image form:

    I routinely run static and dynamic analysis on the rippled codebase – there have been no critical vulnerabilities discovered through that process, and the things that have been found are usually false-positives or intentional (e.g.: a case statement not terminated by a break, when the intention is to fall through to the next). In addition to using automated scanning tools, manual reviews of the code by multiple people have failed to identify a single vulnerability and the minor things have been found (typically, variable shadowing or throw clauses outside a try block when the intention is to invoke terminate) have long been fixed. I doubt that a single, actual vulnerability has been identified in rippled. But if they will produce specifics, then I’m happy to take a closer look.

    Now, let me be a bit more specific: the latest static analysis run was against 0.50.0-b1; before human review, the static analyzer determined that the defect rate of rippled was 0.58 – this is below the 0.7 that is typical for open source projects. This figure is not only before a human reviews the results to weed out the false positives but includes things which may not even be bugs.

    Let’s break it down a bit more: in the last static analysis run, 10 items were identified as “high priority” issues and; some were in external sources after review, <u>every single one</u> was either a false-positive, caused by the analysis engine proceeding down an impossible code execution path, or intentional.

    Most of the medium and low priority items involved members variables that the analyzer reported were not initialized inside constructors: of those, approximately 60% were, properly, initialized by the member variable’s own default constructor. The rest were, intentionally, left uninitialized either because an appropriate value was not available or because it was not needed.

    Manual inspection revealed that in all those instances the variables are properly initialized by a write before being actually read. The “low priority” issues focused mostly around indentation involving our use of  the JLOG macro.

    After triage and weeding out of false-positives and intentional items identified as high priority, and just a few of the “medium priority” items that are the result of the analyzer not properly understanding the semantics of the code, the defect ratio plummets to ~0.2. What still remains is… well… not very much and it would be possible to eliminate them with some changes to the code base, but some of those changes might impair the overall readability and structure of the code.

    I’d rather not inconvenience humans for the benefit of a program.

    Ironically enough, our code auditing and static analysis efforts have found more bugs with external code that with rippled code. For example, we identified and fixed defects with [url=https://github.com/facebook/rocksdb/pulls?utf8=%E2%9C%93&q=is%3Apr%20is%3Aclosed%20author%3Anbougalis]RocksDB[/url] and [url=https://github.com/boostorg/coroutine/pulls?utf8=%E2%9C%93&q=author%3Anbougalis]Boost Coroutines[/url]. At least bugs are getting fixed, right? [emoji3]

    Anyways, to make a long story short, there are two points I want to make:

    If the number quoted in this study is supposed to represent vulnerabilities in the rippled C++ codebase, then I can only imagine that someone run the code through a static analysis engine with the settings cranked to high and blindly copied a number without doing any manual review or triage of the code. As such, the figure is not only unreliable but useless.

    My coworkers on the C++ team, through hard work during development and harder work during review, produce code of exceptional quality. And we go beyond careful coding and thorough internal reviews: we use various different static and dynamic analysis tools and other techniques to continually audit the codebase and ensure its short- and long-term health.

  • ShadowOfHarbringer
    1 week ago ShadowOfHarbringer

    I don’t know about the tests, but is Ripple still a thing ?

    I mean seriously, who even uses that thing ? What is even the point of it existing ?

    • Schleicher65
      1 week ago Schleicher65

      Looks like it is still a thing.
      https://www.bitstamp.net/article/bitstamp-introduces-xrp-trading/

    • rancymancy
      1 week ago rancymancy

      Who uses it? How about this list?

      As for the point of it, it’s a distributed and (at least potentially) decentralised exchange. It’s like Bitstamp or Poloniex except that users have the ability to choose for themselves which assets can be traded (you can issue your own coin in a single transaction), and unlike one of those centralised exchanges, the accounts and transaction databases are truly secure and can’t be hacked, in the same way properly derived and stored Bitcoin accounts can’t be. It’s positioned well to become the de facto upgrade the core of the banking system of value transfer between institutions. Currently, banks using it can save up to 60% in settlement costs. It also has a “block-time” of 3-4 seconds, so transfers as cryptographically secure as Bitcoin can happen in near real-time. * (“block-time” isn’t really the right term given the way Ripple works, but it’s analogous enough.)

      It’s very useful. I also use it, and there is an active user base at the above linked forum. Ripple has been largely in a testing and R&D phase for the past couple of years whilst also working behind the scenes to forge banking relationships and overcome significant regulatory hurdles – something that may likely end up benefiting other blockchain and crypto projects.

  • PetarPetrovicTrades
    1 week ago PetarPetrovicTrades

    Well if they released the paper covering their tests we should bring this to doge dev team to look at these vulnerabilities as they are not welcomed here.

  • sciototrails
    1 week ago sciototrails

    Out of the 25 they charted dogecoin ranked 21rst for having the most vulnerabilities. If I am reading the chart right. Title is misleading because CERT is according to the article independent of the government.

  • FranklinScudder
    1 week ago FranklinScudder

    most github stars (rightmost column)

  • tomcarbon
    1 week ago tomcarbon

    seems like a pretty decent report card. Pretty hard not to see the word DOGECOIN at the top of the list. I like the placement.

    +/u/dogetipbot 98 doge verify

  • dogetipbot
    1 week ago dogetipbot

    [wowsoverify]: /u/tomcarbon->/u/sciototrailsÐ98Dogecoins ($0.0192913)[help]

  • 8btccom
    1 week ago 8btccom

    That’s correct. CERT believed that’s the most popular one.

  • 1 week ago JoelKatz

    I have now posted an official response to this report. https://ripple.com/dev-blog/response-china-cert-report/

    An excerpt: “Again, Ripple recognizes the importance of security researchers, and we take any reports of security vulnerabilities very seriously. At this time, we do not feel confident in the accuracy of the CERT report and further, and based on the way in which the report was published, we question the legitimacy of the reporting body. We are confident in our processes and our codebase, and expressly state that this report identifies no actionable items and our review, in response to it, found none either.”

    • 1 week ago Joy

      Hey, glad ripple has given the response. 8btc has Chinese news site. I wish 8btc can translate Ripple’s response into Chinese and see how CERT will answer back. I think it’s a good thing for CERT to report its audit on Blockchain softwares. Oversight from outside and discipline from inside all contribute to high-quality software. Of course, outside monitoring should disclose more details.

      • 1 week ago JoelKatz

        We are having it translated and will forward it both to 8btc and to the authors of the report.

        This kind of automated testing produces almost entirely false positives. You do it because it might find one or two real issues in the hundreds of things it detects and that makes it worth it. When you run these kinds of tools on projects that already use them, they will produce nothing but false positives because all the issues that can be found by these tools have already been found.

        The rippled code is open source. That’s why these guys were able to run these tests without our cooperation. Anyone can do it. And if they find an exploitable bug, they can exploit it to steal assets. Or they can report it to us to claim a bug bounty.

        There are not going to be a number of bugs that are this easy to find that have actual security implications. There are probably real bugs in there, no software is perfect, but you can’t count them this easily.

  • dawangzi
    1 week ago dawangzi

    omni=holy shit

  • sjoelkatz
    1 week ago sjoelkatz

    I have now posted an official response: https://ripple.com/dev-blog/response-china-cert-report/

    The key part: “Again, Ripple recognizes the importance of security researchers, and we take any reports of security vulnerabilities very seriously. At this time, we do not feel confident in the accuracy of the CERT report and further, and based on the way in which the report was published, we question the legitimacy of the reporting body. We are confident in our processes and our codebase, and expressly state that this report identifies no actionable items and our review, in response to it, found none either.”

  • GeriGeriGeri
    1 week ago GeriGeriGeri

    http://imgur.com/a/mffsA

  • shibe5
    1 week ago shibe5

    Interesting, Dogecoin has much more lines of code than Litecoin.

  • Astrosin
    1 week ago Astrosin

    Yea noticed to. Maybe it’s trajectory calculations already on board for this moon thing….

  • MrDuke67
    1 week ago MrDuke67

    The official response from Ripple by David Schwartz:

    https://ripple.com/dev-blog/response-china-cert-report/

  • llildur
    1 week ago llildur

    like a boss 🙂

  • OldFartWithBeard
    1 week ago OldFartWithBeard

    It is an international naming system for found security vulnerabilities. ‘a CVE’ is shorthand for one such assigned name.

    https://cve.mitre.org/

    https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures

  • -o-o-o
    1 week ago -o-o-o

    Bruce Wanker has not weighed in yet I think I’ll wait for his opinion.

  • dazlightyear
    1 week ago dazlightyear

    Just in case anyone was taking this report seriously, here is the official Ripple response:

    https://ripple.com/dev-blog/response-china-cert-report/

  • dranster
    1 week ago dranster

    The OP does not know how to read reportsBTS2.0 is the most secure blockchain project as per that reporthttps://steemit.com/blockchain/@dana-edwards/bitshares-2-0-is-one-of-the-most-secure-blockchain-projects-while-ripple-is-the-least

  • hl5460
    1 week ago hl5460

    In December 2016, China CERT released a 17-page security audit report of blockchain software. As per the report, the audit was conducted in October 2016 and released later as “open” document. The report examined 25 open-source blockchain projects, categorizing the vulnerabilities found into 9 classes. A total of 746 high-level attack vectors are detected. Ripple is rated the most insecure one with over 223 highly risky bugs.http://news.8btc.com/blockchain-software-security-report-by-china-cert-ripple-the-worst

  • JoelKatz
    1 week ago JoelKatz

    My official response is here: https://ripple.com/dev-blog/response-china-cert-report/TL;DR: It looks like they just ran a static analysis tool against a combination of security sensitive and irrelevant code, totaling the number of potential issues detected by automated, static analysis. This is almost completely meaningless because the vast majority of issues reported by such tools are false positives with no actual security implication. But it’s doubly meaningless when you use it on code that already uses that exact same methodology because every issue that can be identified by this method has already been found and fixed.

  • Hueristic
    1 week ago Hueristic

    Quote from: dranster on Today at 03:01:00 AM
    Most inaccurate title…..  Did you learn your English from a baby or u must be an illiterate..BTS is the most secure blockchain

    Red Herring much?Thanks for that post OP!

  • Gekko463
    1 week ago Gekko463

    Relative price stability, volume and market cap make it a good way to launder thousands of dollars, if not millions anymore into BTC to move on out.

  • Hueristic
    1 week ago Hueristic

    Quote from: JoelKatz on Today at 03:19:55 AM
    We now have an official response to this report at https://ripple.com/dev-blog/response-china-cert-report/“Again, Ripple recognizes the importance of security researchers, and we take any reports of security vulnerabilities very seriously. At this time, we do not feel confident in the accuracy of the CERT report and further, and based on the way in which the report was published, we question the legitimacy of the reporting body. We are confident in our processes and our codebase, and expressly state that this report identifies no actionable items and our review, in response to it, found none either.”

    Looks like their response is the illiterate one of the two. Fixed that first one for them. And further, am not touching that last sentence.

    • 1 week ago JoelKatz

      Do you disagree with our assessment that they just counted the number of potential issues reported by automated detection software without actually looking at whether the potential issues were actual issues with security implications?

  • abolish_karma
    1 week ago abolish_karma

    NUMBER #1! NUMBER #1!

  • Spoetnik
    1 week ago Spoetnik

    All i would have to think about Ripple is if the system is controlled by a central closed source point..then if that point is exploited then the whole entire thing falls apart like a house of cards.Then we could end up with another GOX or Cryptsy going on where they would end up lying for ages and cooking the books behind closed doors.I would say those are the last coins on earth i would touch.I have never owned a Ripple coin or Bitshares nor would i.All records of my activity on any site would prove this easily too.I don’t support ICO scam scheme coins for profit.Guys, just imagine all those Big Banks the Ripple guys say are using Ripple..What happens with them when they get hacked ? 

    • 1 week ago JoelKatz

      There is no central closed source point. All the source code used to operate the network is public. There is no way to cook the books (unless there’s a bug in the public, open source code) because the only way to change a balance is to provide a transaction signed by the owner of that balance. That’s the fundamental design concept for pretty much all public ledger software.

  • abolish_karma
    1 week ago abolish_karma

    For some reason it’s pretty enjoyable seeing an operational tipbot, all the while most other tipbots(inluding several bitcoin ones) has given up the ghost.

  • jacafbiz
    1 week ago jacafbiz

    There are some things common to both Ripple and Bitshares1. Both are Proof of Stake coin2. Both have more than  billion tokens3. Both are centralisedI’m not surprised about the report at all. I think we need independent research like this to expose flaws like this to protect investors

  • dranster
    1 week ago dranster

    Most inaccurate title…..  Did you learn your English from a baby or u must be an illiterate..BTS is the most secure blockchain

  • JoelKatz
    1 week ago JoelKatz

    We now have an official response to this report at https://ripple.com/dev-blog/response-china-cert-report/“Again, Ripple recognizes the importance of security researchers, and we take any reports of security vulnerabilities very seriously. At this time, we do not feel confident in the accuracy of the CERT report and further, and based on the way in which the report was published, we question the legitimacy of the reporting body. We are confident in our processes and our codebase, and expressly state that this report identifies no actionable items and our review, in response to it, found none either.”

  • kelsey
    1 week ago kelsey

    Quote from: JoelKatz on Today at 03:19:55 AM
    expressly state that this report identifies no actionable items

    well i can think of atleast one painfully obvious reason why  Quote from: JoelKatz on Today at 03:19:55 AM
    and our review, in response to it, found none either.”

    which validates the rating  

  • hl5460
    1 week ago hl5460

    Quote from: JoelKatz on Today at 03:19:55 AM
    We now have an official response to this report at https://ripple.com/dev-blog/response-china-cert-report/“Again, Ripple recognizes the importance of security researchers, and we take any reports of security vulnerabilities very seriously. At this time, we do not feel confident in the accuracy of the CERT report and further, and based on the way in which the report was published, we question the legitimacy of the reporting body. We are confident in our processes and our codebase, and expressly state that this report identifies no actionable items and our review, in response to it, found none either.”

    That’s really quick response.

  • GBG-glenn
    1 week ago GBG-glenn

    Sorry, a bit unclear. What i meant was that it’s a system that will be in control of the financial institutions. It’s a project where they have a big finger in the game compared to other cryptos where they don’t get to decide anything in terms of development and rules.

  • goodvibeswanted2
    7 days ago goodvibeswanted2

    I agree. Changetip is shutting down, and I will miss it dearly. I used it exclusively until today in fact. I’ve just started to learn about dogecoin and more about cryptocurrancy.

  • goodvibeswanted2
    7 days ago goodvibeswanted2

    I thought that was Taiwan.

  • tommytrain
    6 days ago tommytrain

    Fair enough, probably not quite entirely accurate given there are 60+ countries making each their own rules for banking regulation and this is the major hurdle to interoperability which cross-border FX solutions like Bitcoin and Ripple are attempting to address. If FIs were more properly organized and “centralized” protocols for improving interoperability wouldn’t be needed, instead there is a still a healthy competitive market for FX services.

Please sign in first