Fast Pay "Exploit"

So I hear a lot of talk about this, and was bit by it on my JEVN 3.3 vendor, causing me to give away a 1000 linden product for nearly nothing.

I can't reproduce it on my own scripts that use fast pay.

Am I correct in assuming that this "exploit" is just due to the vendors trusting fast pay to pop up a modal dialog that prevents world interaction, and not checking the amount actually paid?

Can you post anything else you know on it? What have you heard? What was your own experience?

There is a bug with child prims and scripts changing states - sometimes the Pay option is still available in the pie menu, even if the script doesn't have a money event handler in that state. So a user could end up paying money to an object, but the script would not get notified. But what you're talking about sounds like the reverse of that.

Now that JEVN has come out with an update to patch it, I think full disclosure won't hurt. Other vendors that may not be aware of the problem may need this information to be able to fix it.

Also if anyone still has JEVN 3.3 vendors out in the world you need to upgrade them ASAP!

I'm pretty sure the way it goes is this. Click pay when the vendor is displaying a cheap item. It pops up a fast pay with the cheap price. Switch to a different, more expensive item. Click the fast pay button, it gives you the expensive item at the cheap price.

At least that's as near as I can figure. esmay says it is a LL bug that caused the problem. I'm assuming the pay dialog used to be modal and prevent world interaction.

Now there's a lot of assumption here. I've not been able to reproduce this is any of my scripts, but then I always check the actual amount paid. I was bit by it when someone bought an expensive item from one of my JEVN 3.3 vendors for the price of a much cheaper item.

If anyone knows better, be sure to speak up, this is just the situation as I understand it.

Thanks. If it's just the fact that the script wasn't checking the amount received, that's not a big deal. If there's something else going on, I'm sure I'm not the only one who would like to know I don't remember if the pay dialog is/used to be modal or not.

I don't remember either. And I would also like to know if something more is going on. There's a scathing post on Linden Answers about this, asking why it isn't "fixed" yet... which leads me to think it might be more than what I have laid out here.

Sounds like the JEVN vendors simply aren't checking how much they were paid versus how much the item actually costs. When you pay an object, the money event will tell you how much was paid into it. It doesn't matter WHEN the pay box was opened. (which sucks, see below) So if selecting pay on a cheap item, switching to an expensive item, and then paying gets you the expensive item for cheap, it's the scripter's fault.

Isn't this the 2nd time a major exploit was found in the JEVN system?

Now as to an actual problem, I REALLY wish you could could somehow set a hidden parameter on the paybox, which the paybox will send to the money event when someone pays the object.

Problem: You have a vendor full of objects all priced the same. If one user opens the paybox to buy an item then another user changes the item before the first user actually hits the pay button the first user will get the wrong item. As I mentioned above, I can check to see if the amount paid is the same as what the item actualy costs, but I can't tell WHAT item they opened the paybox on.

I need someone to help me in a simple couple of scripts... please contact me in [email]habisg@yahoo.es[/email]

Good point, some kind of a transaction key attached to the pay event might be nice. The complex vendor-like systems I've worked on, I set up a session which knows the "current user", so a different user won't be allowed to change th evendor to a different item.

Right Ziggy, I thought about doing something like that, but again the paybox disappoints... Say someone clicks around on the vendor, and you've got it set up to timeout their session after a certain interval. What if that person opens the paybox during that interval? You have no way of knowing, and additionally there's no timeout on the paybox so that even if you did know, you couldn't set a reasonable session length because the paybox could stay open forever.

And just as I'm typing this, the DUH moment comes to mind. Altho it would be pretty kludgy for the end user... When you recieve payment, you could send a dialog asking if the current item is the item they wished to purchase, and wait for a response before sending the item or giving a refund. And if you don't get a response in 2 minutes (the timeout for dialogs,) refund their money.

If the money event comes in and there's no valid session, issue a refund. That should take care of timing out a session. If someone else comes along and opens a new session and then the old user clicks the pay button (from a previously opened pay menu), then the ID won't match the current session user, and again you issue a refund.

Yes, it's not fool proof, and it's a pain to put in so much checking into the script. But the number of ways in which this can be broken is significantly fewer than if there's no checking at all.

Now that I think about it, I'm not sure how you would have the pay return extra information. Maybe a script variable, and when the user selects the pie menu, the server records the value of that variable, and then sends it back when the money is actually paid? That might be complicated to implement. If pay were handled differently, like dialog, where the script explicitly generates the menu at that instant - then this could be done, I think, because the script could set the key for that pay menu.

Ah well of course, about refunding on an invalid session. Dur moment for me there.

What I was thinking is adding a variable (integer maybe) to the llSetPayPrice function and money event. I'm already changing the "fastpay" feature with llSetPayPrice every time someone changes the item. So when you open the paybox it gets that integer, and then when you pay it returns that integer to the money event.

I guess the sessions like you suggest would be the best way to do this otherwise. I just hate locking things up for everyone else because one person is using something. But I guess that's really not an issue most of the time.

Ah, I see. Yes, I can see how that would work for your case, and probably for most generic vendors. But if I look at the overall use of llSetPayPrice, I can think of some situations where adding an integer to it won't help out much.

Ech, sounds like scripts making assumptions on things that weren't definite
The only thing you can EVER know from a money event with any certainty is the key that paid you, and the amount they paid!

Relying on a UI element is bad, bad, bad. *tuts and shakes head*

Getting items for cheap? Pssh, a while ago I could have gotten them for you for free!

If you're really worried about that problem with someone switching the current item out from under the customer, make the items all a slightly different price, like L99, L98, L101, etc. If someone pays L101, you know which item they wanted.

Linden Lab have replied to me on both the forum and in an email from development that the fault is due to be fixed in an up and coming release.

I will not go into details of what the bug is except it is still there.

To safegaurd yourself - just do as suggested in the threads above - check the amount in the PAY event.

Always check the amount in the event. Also, there can be a race-condition problem as well.

Consider the SLBoutique.com wallet. If it relied upon email to send fund information (which is doesn't), a problem could exist:

(1) User could get wallet
(2) User could remove script from wallet even though its no-modify
(3) User could put script into a new prim
(4) User could create a second script in the new prim set to pay back to user
(5) Race condition is set; llGiveMoney would often pay the money back to user instead of to SLBoutique

When doing these things, its a good idea to often check llGetCreator, and if it doesn't match, shoot yourself an email and execute an llDie(), then arrive at the scammers place with shotguns!

I've always felt the money event is set up such that bad scripting habits are FAR too easy to create major security holes.

Regards,

-Flip

A few words of advice, don't trust LSL to do things correctly if it's important. If there is a way to check if something has gone wrong, use it. In most cases, the penalty in script runtime speed is worth it, especialy if it's mission critical.

When I was writing the wiki page for llSetPayPrice, this was nagging at the back of my mind (though I just figured that everyone would see the exploit). You should always be figuring out how to break your own scripts. If you aren't, you should be paying someone to do it for you.

Isn't that a little like the pot calling the kettle black ?

If you thought it was important you should have mentioned it - much like Linden should have designed for it.

You're talking about people scripting vendors that don't even bother to check what the person is paying for =S

There are plenty ways around it, namely tracking the item, and checking to see who changed the vendor. ie if I change the vendor to a new item, and I then pay it, then you know that's the item I want. But if I click to pay the vendor but someone else changes the item then it should ask if that's what I wanted. ie keep a check of who last touched the vendor and ask confirmation for anyone who pays but doesn't match.

hasnt teh jevn vendor system been, like, 'sploited a couple times already?

and peeps keep using it :/

I think you are mixed up. If the script I owned did llGiveMoney to me, it would come out of my account and go back into it. Doesn't matter if they wait 10 minutes, there's no race condition.

This has nothing to do with the JEVN system - it affects everything.

People seem to have caught the note from Esmay - which, commendably, was released as soon as I asked her if the JEVN system was affected, and thought "here we go - another JEVN exploit".

Incidentally the new 3.4c JEVN had already been altered to check the payment amount before I informed Esmay of the new bug - so "NO - it's not another JEVN 'sploit' - its an LSL bug that is system wide".

(And I have just switched some of my vendors to JEVN's - so I have every confidence in them )

I'm sorry, it's not a bug. It's poor coding. And I'm sorry for repeating what others have said too.

When I made a set of vendors I set them up with automatic fast pay buttons. One very simple, very obvious test made it clear that this wasn't exactly the solution - two items, different prices choose to pay on one and change thing for sale and buy the new one at the old one's price. The solution? Check how much they paid against how much the user has set the new item for sale at. Whether you give 100% refunds for overpayment, or give the new item and a refund of the excess is up to you - 100% refunds when they've underpaid though and tell them why.

It's not 100% foolproof - you can get different items that are the same price that way, but they get something of similar value at least, probably don't try it again if they're trying to "exploit" and there are, IME, few enough genuine mistakes this way that the vendor is willing to cope with a swap (that's speaking as a vendor and a buyer btw when it's happened). If you're selling that much move to an island, you can probably afford it, and put up one vendor per item, it is the only way to be entirely safe.

Whilst rewriting the code would be nice changing SL so it has hooks for X right-clicked me, X chose pay etc. that are accessible within lsl - I have a strong suspicion that multivendors will vanish if you try as the virtual machine falls apart under the load.

I don't particularly have an axe to grind against JEVN but it's not a exploit, it's an undertested product by the sound of it.

You are referring to a different topic - a known issue with multi user capabilities ( or not ).

What has been reported is a bug and is nothing to do with whether the object in question is a multi vendor, a single vendor, a slot machine, a lottery ticket - it is purely to do with something that happens to llFastPay.