The initWallet function should have been marked internal, but was instead not marked. Unmarked functions default to public in Solidity, so anyone can call that function and reinitialize the wallet to be under their control
Based on the time of your post, I suspect you meant to link to:
https://github.com/paritytech/parity/blob/4c32177ef3f4521c66...
The initial poster posted this link: https://github.com/paritytech/parity/blob/master/js/src/cont...
Where "master" is the branch which normally has the latest code. And #L216 automatically scrolls down to the 216th line.
The issue is that line isn't permanent since the code in the master branch is subject to change. So in order to make a reliable link, you can link to the ref [1].
Like this: https://github.com/paritytech/parity/blob/4c32177ef3f4521c66...
You could also do it with the short ref (4c32177e): https://github.com/paritytech/parity/blob/4c32177e/js/src/co...
Normally you'd have to scroll up to the top right of the document and grab the short form it, e.g. "6b0e4f9" and replace it with master. Note that's only the ref of the last change for that blob (file) [2].
If you click the line number on a GitHub file, it will add the #LineNumber to your URL.
From there, press Y, this will replace master with the latest commit of the repo.
[1] https://git-scm.com/book/en/v2/Git-Internals-Git-References
[2] https://git-scm.com/book/en/v2/Git-Internals-Git-Objects
But yes it seems pretty asinine to use global by default for (not so) smart contracts.
Anyway, I think parent's point was to say this behavior already has been seen in javascript. Actually, it may even be inherited from javascript. When I first looked at solidity last year, I was under the impression it was a modified version of javascript, like unity3d's one. Nowadays, solidity landing page reads "high-level language whose syntax is similar to that of JavaScript", so not sure if it still is (or has ever been, for the matter) derived from something like v8 or rhino.
The reason for that choice seems not far fetched : it's not uncommon, when wanting to add scripting to something, to go with javascript, since it's arguably the most known language, developers knowing "<their main language> and javascript", especially webdevs (a blockchain app project, lisk, even made html/css/js the defacto mean to build apps). Of course, fintech is an industry where the usual values from webdev (release early, release often) have disastrous results.
"use strict";
foo = 1;
var bar = 1;
Language design is actually notoriously difficult in general[1], but if you're doing language design for a security-critical language[2]... well, that requires actual mechanized proof, IMO. Not just proof of "design", but proof of the implementation. Anything else is a huge gamble. (And I'm sure there are some 'investors'/gamblers who made off very well.)
[1] Beyond surface-level, obviously.
[2] We're talking about 0.0001% of the general population here.
Absolutely, few people really get this. Even those that do get it generally don't know what it looks like in practice because it's so rare.
In case you're curious about what it looks like in practice (at least one way), we presented direct user code compilation and verification[1] in Jan for our smart contract language Pact[2].
The idea that you can write a doc test that triggers a formal verification about some aspect of your code is, for lack of a better term, strange and yet the power to weight ratio is just off the charts. For the first few days that the system started working (I built the FV portion, Stuart the language + H-M type system) I thought it was broken... turned out we just had a bug in our demo code that we never noticed.
Usually, tests check the things you know to check so when they find something it's not a surprise what they find. Sometimes you can fuzz and randomly find something, which is cool but doesn't guarantee that there isn't a problem somewhere else. However, FV just feels uncanny (as a dev) because the test either finds a problem in the code -- and tells you how to replicate the bug -- OR proves that a problem cannot exist.
[1]: https://youtu.be/Nw1glriQYP8?t=1071
[2]: kadena.io/pact
I'm not sure I understand this sentence. Are you doing doctests, or are your doctests statements of formal properties, or have you abandoned that and are now doing formal specs->code type things?
(I mean, I understand the pressures of academia, but... ridiculously bad timing, yeah?)
At some point, it's time to blame the tool and not the user. Moreover, it's not like people didn't see this coming, myself included[1]. I mean, who really thought that basically taking JavaScript and swapping out the DOM for a bank account wasn't going to end badly? But then again, maybe I've spent too much time at in the SEC/finance where "move fast and break things" engineering gets you shown the door quite quickly. That mantra's fine for a number of domains but finance isn't one of them as one bug can bankrupt the company (see: knight capital).
It really just underlines the need for a safer/better approach. Formal Verification has to be part of that story. A language that was designed with safety in mind has to be another part.
Also, not an academic (yet at least). Cofounder here: http://kadena.io
[1]: https://goldsilverbitcoin.com/jp-morgans-blockchain-research...
I don't see any justification for this statement. The bug could easily have been discovered if there had been better auditing. That the auditing missed the bug doesn't prove that it's "practically impossible" to write secure code with Solidity.
In any case, nothing is stopping you from porting your formally verifiable language to Ethereum. The EVM is not Solidity. In fact there is already a project underway to create a verifiable programming language for the EVM.
Honest question, what would be required in your opinion for before we start considering if the tool is at fault? I ask because, if you're of the opinion that it's never the tools fault then I'll never be able to justify my point of view. Which is fine, we can disagree. I'm all for massive experimentation in this area and thus need people who disagree with me to do research down the other lines.
Also, it's not that I think it will always be practically impossible just that currently (and for the next several years at the very least) it is. We'd need way better tooling and the type of tooling needed is incredibly advanced stuff. We're not talking about a build system here, we're talking about formal verification which is one of the most advanced tools you can build. I can only think of one tool that can formally verify user generated code (cryptol) and even then it's only for a small subset of C/Java that applies to crypto work.
It's not that you can't write safe solidity contracts today but that IMO an element of luck is required. You need to get the right auditors, have them do a good enough job, implement the logic a certain way instead of another and thus avoid a bug no one has thought about before, etc... When people's money is on the line, needing luck is terrifying.
> nothing is stopping you from porting your formally verifiable language to Ethereum
I wish this were true but it isn't. We spent months trying to see if there was a way that it would work because we would have preferred this approach. The EVM itself is stopping us (as well as the shape of the Eth blockchain but we could probably have worked around that problem). Pact is interpreted, so while we could make an EVM version technically it's practically unworkable -- there's nowhere near enough gas to run the interpreter. We couldn't compile directly to EVM either as the EVM just doesn't do enough[1] for you. It's closer to a 1980's era CPU ASM than a modern VM (like the JVM). Moreover, the Pact runtime does a lot of things for you (as a safety feature) that the EVM just doesn't have a notion of. Even then, while all of the Pact-compiled-to-EVM code would work and be safe, we couldn't protect it that code from EVM code that doesn't play by Pact's rules. Moreover, supporting all the extra things that Pact does for you would make it, again, run out of gas on EVM.
This discussion is very similar to putting Ed25519 on the EVM. While you can technically implement it in EVM, it's just too gas-heavy. It's best to extend the EVM itself to do more.
That's the thing about having the EVM be Turing-complete, it makes people think that "it can do anything and thus abstracts over the problem thus solving it." This is technically true but not practically true -- all you are doing is punting a huge number problems/required features (like dispatch and module loading) down the road for the language to figure out. In a gas-metered context, every feature the language adds because the EVM lacks it costs gas and thus makes a number of features impossible in practice.
> In fact there is already a project underway to create a verifiable programming language for the EVM.
Mind linking me to it? I collect references to smart contract languages at this point and haven't heard of this one. I know the people working on the EVM + solidity formal verification project personally (well some of them at least) and it's still years away.
[1]: Great technical discussion about EVM here -- https://news.ycombinator.com/item?id=14689792
The programming language being partly at fault is not the same thing as it being "practically impossible" to write safe smart contracts that language, in my opinion.
I was taking issue with your wording, which I think gives a misleading impression of the attainability of secure Solidity code. Your follow up comment is more measured, as it doesn't characterise the need for some measure of luck to write a safe smart contract as writing a secure smart contract being "practically impossible".
Maybe we're using different definitions of "safe", but I think many use my definition, in which case your statement would give them a misleading impression.
>This discussion is very similar to putting Ed25519 on the EVM. While you can technically implement it in EVM, it's just too gas-heavy. It's best to extend the EVM itself to do more.
Yes I am aware of that. There is research being done on possibly switching the EVM to an Ethereum variant of Web Assembly, i.e. eWASM, which will be able to efficiently execute a wider range of functions.
Further on this point, I have to admit that I am not qualified enough to comment on the portability of Kadena to the EVM, so I'll take that back. What I meant to dispute was the notion that formally verifiable programming languages cannot be built for the EVM, which is the takeaway that I got from your comment. A PL of this type is in fact being developed [1].
Thanks for the link to the technical discussion on Solidity.
Then, in another section of the documentation, when talking about function types [2], not specifying internal or external defaults visibility to internal.
It doesn't seem like the simplest or most consistent way to express these concepts, and certainly not the safest way.
[1] http://solidity.readthedocs.io/en/develop/contracts.html#vis... [2] http://solidity.readthedocs.io/en/develop/types.html#functio...
Your honour, in my defence, the contract clearly specified that anyone could reset the wallet, and if that's not what they wanted, they shouldn't have agreed to it.
So like most court cases, it will simply be a matter of human influence winning the case.
It's not even in the category of weird timing attacks or complicated internal states allowing unexpected state transitions -- this is a trivial bug that could be spotted by viewing the contract in Remix (the Solidity IDE).
There are certainly some weird edge cases in the Ethereum VM programming model that are hard to UT, and I think that dev efforts in this area are under-resourced (e.g. it's currently impossible to test time-dependent contracts as there's no way of mocking out the clock in the simulated blockchain).
If you are considering writing a smart contract, read and re-read https://github.com/ConsenSys/smart-contract-best-practices, and then write UTs for each of these cases so that you can convince yourself that you've covered them.
Relevant to this bug:
> Understand that your public functions are public, and may be called maliciously. Your private data is also viewable by anyone.
This philosophy permeates the community of Etherum development.
Bitcoin disabled most of the smart contracts op codes for a very good reason.
I wouldn't recommend putting anything of value into an Etherum smart contract and find a project with more responsible developers who take a more "wait and see" approach.
it should not be this easy to lose sixteen million dollars
Financial institutions are accurate to tiny tiny fractions of percentage points. Not "eh we got 99% of it right".
I'm amazed that otherwise intelligence people really believe this is a better system than fiat currencies + banks.
Now why hasn't there been as much publicity about this? Is it because Vitalik Buterin is a wunderkind genius who simply beat them to market? Nope, the Bitcoiners are simply being more responsible and making sure they get the formula right before rushing to market.
Please see this article to get an idea of the personalities involved:
http://www.newsbtc.com/2016/08/17/gregory-maxwell-vitalik-bu...
If HE can't get it right, what business do you have running around saying that anyone who can make a webpage can make a decentralized application?
We are playing with money. Dealing with attackers is not as simple as rebooting your server. Mistakes mean irreversible loss.
The devs in this industry are way over their heads and nobody is willing to admit it, because doing so destroys the entire core value prop of Ethereum, the poster child of the current bubble.
Though crypto has risen past the high point of each of these bubbles, each price point can be definitively classified as a bubble in it's own time, and was followed by a crash that wiped out >70% of the market cap over the coming months/years.
Though it did recover, that doesn't mean it wasn't a bubble.
I believe cryptocurrency is going to be bigger than e-commerce is today. But it's not there yet, and it shouldn't be valued as though it has changed the world. It hasn't yet, and it's still a few years away at least from doing so.
Don't short hopium.
"If the creator of Solidity, Gavin Wood, cannot write a secure multisig wallet in Solidity, pretty much confirms Ethereum is hacker paradise."
Parity devs may be academically brilliant, and they put out a fantastic client, but the wallet issue shows how lax their development lifecycle has been.
Bitcoin is also stuck in the past. Yes, Ethereum breaks things, but for me it's not about the money but about the technology stack. We're too early in the process to have the luxury of being able to stop innovating.
If I want to play with cool state-of-the-art technology I use Ethereum. For financial transactions I use my bank and/or Transferwise. Haven't quite yet figured out why I'd use Bitcoin for something.
Some projects have started sharing audit results publicly directly in their repos [1]. It's a great read to see common errors and yet unsolved issues that originate in the ERC20 token specification.
[0] https://github.com/ConsenSys/smart-contract-best-practices#i...
[1] https://github.com/status-im/status-network-token#reviewers-...
So I feel obligated to post the full bit (from wikiquote)
>Wonka: [angrily] Wrong, sir! Wrong! Under section 37B of the contract signed by him, it states quite clearly that all offers shall become null and void if - and you can read it for yourself in this photostatic copy - "I, the undersigned, shall forfeit all rights, privileges, and licenses herein and herein contained," et cetera, et cetera... "Fax mentis, incendium gloria cultum," et cetera, et cetera... Memo bis punitor delicatum! It's all there! Black and white, clear as crystal! You stole Fizzy-Lifting Drinks! You bumped into the ceiling, which now has to be washed and sterilized, so you get... NOTHING!!! You lose! GOOD DAY, SIR! [returns to work]
Yeah, as a kid, I too thought Wonka was serious. It took viewing it as a much older person to see the satire there.
[1] https://www.bloomberg.com/view/articles/2016-06-17/blockchai...
[1] https://www.reddit.com/r/badeconomics/comments/6cnzs8/matt_l...
But I think of this issue in slightly different terms that are more simple.
There's a ton of case law about what constitutes a contract that pretty much all countries have. Clearly understanding the contract you are getting into is a prerequisite for the contract being enforceable in most places.
The simple fact is that this is never going to hold up in court when people start suing.
No one gets into a contract with the understanding that they can be robbed, and that's just okay. No rational person would do that. And I think it's a fair case to say that no rational person did clearly understand the contract as presented and agree to it.
The courts are going to to shut this down, in my opinion.
You can't just write into a contract that you might get stolen from or murdered or whatever bad thing and then that bad thing is suddenly okay.
"Okay, this guy didn't read the fine print on that used car loan. Let's go rape his wife and kids now. He said it was okay!"
That's not how it works. Etherium deserves to get hammered for this.
One of the things that cyberpunks fail to grasp is that people don't want a perfectly immutable, fixed system. They want to feel that their sense of justice and moral righteousness can be satisfied. Stuff that drops people off right at "sucks to be you" doesn't really work; there must be some type of recourse available even if it doesn't have a 100% success rate.
Anyone who wants to maintain power in virtually any setting (communal, corporate, governmental) must create an impression of fairness and equity, at least to the extent that a good portion of the people are not willing to risk their [reputations/jobs/lives] to throw off the "oppressors".
It's not an accident that virtually all powerful corporate bosses and politicians are so image-conscious and superficial; it's a matter of survival for powerful people.
For all its warts, a legal system backed by a jury of your peers is still the best way of sorting out the actual intent of a contract when the shit hits the fan.
I did not assign any assertion or position to the OP, only followed up on his thread about the potential ramifications that ETH backers seriously advocate.
And many people do promote the "code is law, and nothing else" idea -- at least Ethereum Classic stuck to it!
It is fine if you don't like those features. But it turns out that a lot of people DO want them.
The people who want to court system can already use the court system. Now we just have more options and choices.
But if someone wants to, they can make it extremely for that to happen.
Good luck finding the anonymous contract creator that set up their contract by sending money through Monero.
Also, empirically, your claim that courts will get involved with ethereum smart contracts just isn't true.
It is not true, because gigantic scandals and contract theft have ALREADY happened on ethereum, and the courts haven't been able to do shit.
Specifically, in the DAO hack, the affected people had enough political influence to get the entire network to undo the ownership transfer that was the result of their own oversights:
https://www.reddit.com/r/ethereumfraud/comments/6bgvqv/faq_w...
If anything, Ethereum is worse because you have to get the entire network to fork (analogous to a revolution or constitutional convention) to fix a mistake, instead of just getting a judge to rule "okay, that's obviously not what anyone meant".
Furthermore, it's far more unequal, where mistakes only get fixed when they affect the most influential users. Seems like a step in the wrong direction.
A system of laws devoid of all ambiguity and emotion isn't even possible, let alone desirable, because at some point these contracts have to come into contact reality, and the humans in it. And these humans happen to be, well: human.
I guess there's an ideology at play that would love to change humans to fit within their neatly arranged algorithms. And if that means some grandmother loses her house because she signed the wrong smart contract when buying cat-food, there'd be a lot expressions of sympathy on Twitter, but she really needs to understand that it's just not possible to do anything about, because principles etc etc.
Here and there, some of these people may, very privately, consider it a feature of the system that others less intelligent than them sometimes happen to die on the streets because of that one Saturday morning where they didn't audit all 500k lines of brainfuck in that contract for chinese takeout.
With less snark: the idea of ambiguity or emotions as being something negative is a somewhat naive view of reality, somewhere on the spectrum between Star Trek's ideal of Spock and the social darwinism of Ayn Rand. It's most often seen in the currently popular misunderstanding of how judges should behave, and how journalism supposedly used to work.
For an example that maybe is a bit less inflammatory than anything about journalism, check any recent threat about the Google vs Uber lawsuit: the presiding judge is almost a legend for his diligence in learning the technology in the Oracle vs. Google lawsuit a few years back. Yet people criticise him for a lack of decorum whenever he uses language that doesn't pretend to be a robot following an algorithm: "This judge is clearly biased! The contract clearly only says $50,000, and there's no law that gives him the authority to say those are USD. When the defendant says it means Canadian Dollars, it's he-said-she-said and undecidable"
Ethereum, as well as things like IPFS that say "Your content is permanent and irrevocable, don't publish if you don't like that", are non-starters because they overlook this core desire to operate under forgiving systems.
Many unfair or distorted legal regimes exist (including, to some degree, the American one), but they all make overtures toward these principles in some form or another. Ethereum et al must correct this if they want widespread adoption.
Some people do.
Source: I am a person who wants this.
153,000 / 93,405,120[0] = 0.001638025838
“Churchill: "Madam, would you sleep with me for five million pounds?" Socialite: "My goodness, Mr. Churchill... Well, I suppose... we would have to discuss terms, of course... "
Churchill: "Would you sleep with me for five pounds?"
Socialite: "Mr. Churchill, what kind of woman do you think I am?!"
Churchill: "Madam, we've already established that. Now we are haggling about the price.”
We've already established that they will fork. Now we are haggling about the price.
[1] http://www.goodreads.com/quotes/300099-churchill-madam-would...
"Would you sleep with me?" "Maybe for a million dollars..."
Says it all, I think, whether sarcastic or not.
How do these smart contract deal with the real world? I can see how they can work for things that entirely involve activities that take place on the block chain (e.g., a smart contract that automatically pays a crowd funded project if and only if it meets a threshold for pledges by a deadline, and refunds the donors otherwise).
But suppose our contract is something like I will pay you $X in Ethereum when you deliver to me 125 bales of Surat cotton, guaranteed to be middling fair merchant's Dhollorah [1], delivered at the Liverpool docks from Bombay on the next sailing of the Peerless.
How do we put all of that into a smart contract? Can a smart contract trigger payment only when the cotton arrives? Can it check to make sure it arrived on the ship specified in the contract?
And what happens if it turns out that there are two ships named Peerless, unrelated to each other, one of which is sailing from Bombay to Liverpool in October, and one in December? I only know about the December one, and it is on that one that I'm expecting the cotton. You only know about the October one, and so it is on that one you send the cotton. The cotton arrives before I'm ready to deal with.
Unless dealing with all that can be included in the smart contract, and executed by the smart contract without human intervention, lawyers will still be needed...and they will be needed almost as much as they are now.
PS: my cotton hypothetical is based on a real case: Raffles v Wichelhaus, EWHC Exch J19, (1864) 2 Hurl & C 906. There really were two unrelated ships both having and neither deserving the name Peerless, and both working the India / England trade routes, both scheduled for Bombay to Liverpool, one in October and one in December.
[1] Dhollorah is a very dirty cotton of a longish staple, which when cleared is very white, as if bleached. For for more than you probably ever wanted to know on this and other types of cotton, see the book "Cotton Spinning and Weaving: A Practical and Theoretical Treatise" by Herbert Edward Walmsley, page 71. It's from the late 19th century and is public domain now I believe, and you can find it on Google Books.
Sir that is a prejudicial statement and I want it stricken from the record.
More relevantly, creating a synthetic language that's a subset of natural languages will mean that multiple natural concepts will map onto the same synthetic one.
At some point you have to ask yourself whether we really prefer that code be law, with the quality of code that's so common these days, or whether we actually like being able to specify something to a lawyer -- rather than a computer -- simply because the lawyer will return the contract and ask for clarification if something is ambiguous/unclear.
The human-to-lawyer interface is the best contract interface that exists, the only reason we use computers is because they're so cheap and fast. When we dream of AI we dream of having a computerized lawyer, who can ask clarifying questions and resolve ambiguity before it becomes a problem.
If tomorrow I sign a contract with my mobile phone carrier and it turns out that through some loophole in the contract they get entitled to the kidneys of my first born daughter then clearly I have a case to go to a tribunal and get it overturned as it's obviously not a reasonable clause.
I think people arguing that "code is law" (which is simply a modern form of "letter-ism") don't really know what they wish for. I guess is many are going to change their minds when those attacks get more and more common and they lose a ton of money because of an unforeseen and obviously unintended flaw in the contract code.
They can't deal with the real world by themselves, but where they have value in agreements involving real world events is that they allow the real world assessments to be debundled from those aspects of the agreement that can be formalized.
So in the cotton shipment example, the smart contract would have three parties assigned as Oracles that determine whether the correct ship arrives at the correct port on its correct trip. The smart contract would dictate that if 2 out of 3 of the Oracles agree that the condition has been met, then the smart contract will transfer the funds. There could also be a failsafe clause in the smart contract, that is controlled by a set of five oracles, who have the power to override the smart contract if the majority deem that an expected event occurred.
So yes you need human intervention, but only for those parts that cannot be automated. This explicit definition of what the human roles are may encourage better contracts, by forcing the counterparties to spend more time reasoning about which aspects of the smart contract are subject to ambiguity.
This is tautological and therefore means nothing.
I've not worked with smart contracts personally, so take it with a grain of salt, but...
This problem seems to be mostly solved by the information available in shipping manifests; the locations of loading and unloading, the consignee (buyer), container ids, description of goods... all there in a publicly available (at cost) record.
The real difficulty has more to do with verifying the quality - I'll admit I'm at a loss to how that's done today and I can't imagine quality assessors are at the port to verify that container #123 contains the shipment of Grade B+ cotton or map that to an API. As well, what happens when you disagree and your own independent assessor says its Grade B-? This seems like something that would remain up to legal debate; probably denoted in the contract but not verified by it such that lawyers and assessors can handle it should problems arise.
Just my two cents.
Facepalm
Wasn't this lesson learned long ago? C# defaults to private on unmarked members. Why would you ever want to default public?
Haskell is a good basis but the developers need to make the API fool proof. E.g. expose limited effects rather than a big fat "IO" type.
Calling initwallet: https://etherscan.io/tx/0xff261a49c61861884d0509dac46ed67577...
Executing: https://etherscan.io/tx/0x0e0d16475d2ac6a4802437a35a21776e5c...
What kind of brain-dead apes designed this language? This would be a stupid decision in any language, never mind one specifically intended for high-value transactions.
I only wish people had to do that. Shit like this are why professional and civil engineers roll their eyes at the mention of software "engineering". There are best practices and available tools but people employ them far less often than they probably should. In the space, take a look at Kadena's Pact smart contract language. It's not perfect by any means (lisp-religious syntax and its tight integration with Kadena internal constructions, for example) but it is at the least, working on formal verification support.
IIRC, the old Camllight VM was pretty similar (I might misremember, that was literally decades ago); an ML-like language to Michelson compiler is fairly straightforward to write and to prove sound.
I'm happy that they do things the sane way, i.e. focusing on sound foundations rather than on how Javascripty the syntax looks; but I'm afraid the communication isn't as clear as it could/should be. Blessing a compiler for some subset of ML, as a first high level language, would have cleared things up IMO.
The underlying DAG idea has potential. You could have two half-transactions happening on separate subtrees, where A is buying X from B and B is paying Y to A. So A broadcasts "A will buy X from B when B pays Y to A", and B broadcasts "B will pay Y to A when A buys X from B". When the matching half-transactions acquire a common child, the transaction commits. It's a true "meeting of the minds".
You can for example trade user-defined (possible private) assets (tokens) in that way - "Ill send you my bytes for your blackbytes, I send bytes to this address and me can sweep them back after 4 hours, or you can sweep them if payment of X amount of blackbytes is made to my address". It has oracles as well.
> This would be a stupid decision in any language
The problem with cryptocurrency is that they try to be better than the system, but have to relearn all the lessons the hard way. It probably won't take too long before all of it becomes exactly like what banks are now - heavily regulated, etc.
parity.io, the company author of the bug, is a top-notch Ethereum actor. If they can neither get a wallet contract right, nor realise that it's faulty, then who can write and trust any non-trivial Ethereum contract?
How many DAO or Parity trainwrecks before people admit that Ethereum isn't a dependable platform?
ETH and ETC have the same underlying technology and language to write the contracts. So if someone writes a contract it can be used in both variants. The contract may check that it is in ETH or ETC (probably looking for the contract that was added during the fork) but I think very few contracts check this, so almost all contracts are usable in both chains.
So if it was possible to use the Parity contract in ETH, then it's very probable that it was also possible to use it in ETC.
To answer your question: Probably the same bug that was used to steal ETH can be exploited to steal ETC, if someone is using these contracts in the ETC chain. But it's not a problem in ETH or ETC [1].
[1] As other commenters noted, it's a very bad design flaw to make all function public by default. It's not an error, but it makes much easier to write buggy code.