Jump to content

FUD or Legit?


liangran2012
 Share

Recommended Posts

The "National Committee of experts on the Internet financial security technology" in China publish their Security Risk Analysis Report of Open Source Blockchains today.  Ripple is on the list and it seems have a lot of high risk problems. It said Ripple have 223 high risk problems, followed by Ethereumj which have 110 high risk problems.

The report also mentioned both Java and C/C++ code of Ripple are tested, and the JNI feature of Ripple bring lots of high risk problems.

The PDF could be download via below link. The report is written in Chinese.

http://if.cert.org.cn/jsp/activitiesDetail.jsp?id=19

bug_report_001.png

Link to comment
Share on other sites

 

Via Google translate:

Quote

In all the tested software, the overall security risk is relatively serious is the block chain payment network Ripple, including 223 high-risk vulnerabilities. It is noteworthy that the software is likely to be the block detection chain related software in the largest, most users, the most widely used software. At the time of writing, the software company has been including Google, Accenture, including a total of 100 million US dollars of investment, while some large banks have announced that they will join its payment network, including Standard Chartered, Westpac Bank, Bank of Australia and Shanghai Huarui Bank and so on.Considering that the software directly deal with financial assets, and has such a large-scale users, once these loopholes exploited by hackers, will cause immeasurable losses.

 

Response @nikb (thank you, clear answer):

rippl001.JPG

 

 

Link to comment
Share on other sites

1 hour ago, liangran2012 said:

The report also mentioned both Java and C/C++ code of Ripple are tested, and the JNI feature of Ripple bring lots of high risk problems.

1

What is JNI feature?

Java Native Interface (JNI) is a Java thing and completely unrelated to Ripple.

Edited by T8493
Link to comment
Share on other sites

The "Security Risk Analysis Report" was too large to be conducted manually and they had to use some automated code analysis tool.

@nikb stated clearly in the chat that his vulnerability reviews give good, if not excellent results and in this I trust Ripple developers.

It is just a HUMBUG.

Link to comment
Share on other sites

Since "JNI" is mentioned, maybe they also checked https://github.com/ripple/ripple-lib-java?

Which static analyzer(s) are you using? Visual Studio builtin, clang's analyzer and/or a commercial solution?

I guess that some stuff also got lost in translation or misinterpreted. When I ran code analysis stuff against rippled, most issues came up in the external subtrees/projects (RocksDB, snappy, ed25519 etc.) so it seems weird to me that there should be really hundreds of "high risk vulnerabilities" - is there a section about their methodology and did they actually report these vulns to Ripple Inc.? After all, they are a CERT...

Link to comment
Share on other sites

49 minutes ago, nikb said:

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 belowt he 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.

4

Maybe they also included the code in other repositories. Most of other repositories are not actively maintained and code coverage is much lower than 100% (even the code in rippled repository has code coverage "only" 66%).

 

Link to comment
Share on other sites

11 minutes ago, Sukrim said:

Since "JNI" is mentioned, maybe they also checked https://github.com/ripple/ripple-lib-java?

Which static analyzer(s) are you using? Visual Studio builtin, clang's analyzer and/or a commercial solution?

I guess that some stuff also got lost in translation or misinterpreted. When I ran code analysis stuff against rippled, most issues came up in the external subtrees/projects (RocksDB, snappy, ed25519 etc.) so it seems weird to me that there should be really hundreds of "high risk vulnerabilities" - is there a section about their methodology and did they actually report these vulns to Ripple Inc.? After all, they are a CERT...

I don't know what they analyzed; agreed that JNI makes no sense in the context of rippled; you may be right that they looked at other projects as well, but I can't comment on their methodology or their techniques. I'll  only say although words could have gotten lost in translation, I don't think the number was. I suspect that the resulting number is a combination of things: external libraries and with no human review of the resulting reports to weed out false-positives.

Now, to the stuff I can talk about: we use a number of static analyzers - including two different commercial solutions. The more, the better, although it's a bit more work.

 

Link to comment
Share on other sites

How secure is boost itself? I know it's being used by rippled.

Often developers rely on 3rd party libraries and even if they use 2-3 functions, they freely included complete libraries into their projects. I was never a fan of this.

Link to comment
Share on other sites

1 hour ago, Duke67 said:

How secure is boost itself? I know it's being used by rippled.

 

It is very hard to definitely tell how secure boost is, but boost libraries are peer-reviewed and highly regarded in the C++ community. They're also widely used, and often they represent reference implementation which is later incorporated into the C++ standards (i.e. C++ 14, C++ 17, etc.)

 

Other libraries that @Sukrim mentioned (snappy, Ed25519, etc.) are probably more problematic in this respect. However, snappy has been used by Google and other open-source projects for quite some time and it probably works fine.

But Ed25519 - for example - is not standardized at all and it wasn't scrutinized as much as other signature schemes (ECDSA with standard curves).

EDIT: there are maybe other possible "vulnerabilities" in the Ripple signature scheme - for example, use of RFC6979 in some libraries. RFC6979 is less reviewed than other cryptographic primitives. However, if they knew something about RFC6979 that the rest of the world doesn't know, that would be worthy of an academic paper and they wouldn't just include it as one of the 223 high-risk problems.

 

 

 

Edited by T8493
Link to comment
Share on other sites

35 minutes ago, grondiwam said:

If this is substantially wrong, there should be some kind of official response. You wouldn't want to alienate the Chinese market.

Well, R(L) probably can't provide a more substantiated response if it is not known which parts of the Ripple ecosystem are they "attacking" (rippled, Java libraries, JS libraries, C# library?) and if it is not clear what counts as a "high-risk problem".

Link to comment
Share on other sites

 

4 minutes ago, T8493 said:

Well, R(L) probably can't provide a more substantiated response if it is not known which parts of the Ripple ecosystem are they "attacking" (rippled, Java libraries, JS libraries, C# library?) and if it is not clear what counts as a "high-risk problem".

 

Some sort of short response, official but through unofficial channels, is enough. No need for a hard challenge on the result.

In this market, no response is as good as tacit admission.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share


×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.