How many smart contract problems can Oyente detect today？

[xf97]

Hello, I am a graduate student from Hohai University. I just read the paper Making smart contract smarter, and I also used Oyente, I found that the existing Oyente can detect more kinds of smart contract problems than the paper mentioned. Would you please let me know what kind of smart contract problems Oyente can detect now? What are the test criteria for each problem? I'm sorry to disturb you, but I look forward to your reply.

[yxliang01]

@xf97 Referring to https://github.com/melonproject/oyente/blob/6c9d38241449b648909531d09ae0dd5fbd2fcd52/oyente/symExec.py#L111 , the vulnerabilities can be detected are:

• integer_underflow
• integer_overflow
• callstack (Deprecated as this isn't happening in new EVM)
• money_concurrency
• time_dependency
• reentrancy

For the criteria, some of them are described in https://github.com/melonproject/oyente/blob/master/code.md while some in the Oyente paper which you can look into.

P.S. I've seen similar issues raised by you in many other smart contract detector repos. Looks like you are doing comparisons among all these detector? Just curious.

[xf97]

Thank you for your reply, which has helped me. Well, I find that there are many problems in the Ethereum smart contract, and there are many tools to detect these problems. But it seems that no tool can cover all the problems, which may cause inconvenience to developers. If I'm a developer who wants to know if there are some problems with my smart contract, I have to use several tools to test my contract. After getting the test results, I had to ask myself a few questions: Are all the smart contract issues covered? If the results of several tools conflict, which one should I trust? My current investigation is devoted to solving this inconvenience and I hope it will be helpful to you.

At 2019-09-13 01:41:08, "Xiao Liang" [email protected] wrote:

@xf97 Referring to https://github.com/melonproject/oyente/blob/6c9d38241449b648909531d09ae0dd5fbd2fcd52/oyente/symExec.py#L111 , the vulnerabilities can be detected are:

integer_underflow integer_overflow callstack (Deprecated as this isn't happening in new EVM) money_concurrency time_dependency reentrancy

For the criteria, some of them are described in https://github.com/melonproject/oyente/blob/master/code.md while some in the Oyente paper which you can look into.

P.S. I've seen similar issues raised by you in many other smart contract detector repos. Looks like you are doing comparisons among all these detector? Just curious.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[yxliang01]

@xf97 Right. My understanding is that you are surveying different smart contract vulnerability detection tools. There are multiple papers have sort of surveyed the famous tools at the time they published, probably you want to have a look if you haven't. Good luck with your work and yes hope it will be useful to me. :)

[yxliang01]

@xf97 Just my 2 cents, I haven't seen any open-source detection tool covers all known vulnerabilities. While it's possible, there is also some constraints of the techniques they are based on. e.g. hard reason about possibility of integer overflow using solely static analysis. I've noticed that mythx is said to be using both symbolic execution and static analysis to have both accuracy and efficiency. However, it's not open-source and commercial as far as I know.

[xf97]

This field has been developing very fast (ps. the first paper I read about smart contract security detection is "Making smart contract smarter"), based on my current investigation, as you said. The better ones are Mythx, Slither and SmartCheck, who claim to be able to detect a wide variety of problems, although I haven't yet tested the accuracy of these tools. Unfortunately, Mythril and Myythx don't have relevant documentation and specific implementations that allow me to learn more about them. I try to find a set of complementary tools to complete the coverage of smart contract problems, and to ensure good accuracy.

[xf97]

Hello, I would like to know about the impact of money_concurrency. I haven't found any information about it in other documents. Could you tell me why this situation is a bug (in my opinion, it seems reasonable for different execution processes to return different money)? I hope you can answer my question.