List of vendors not checking paid price after using llSetPayPrice()

Ok, there's an easily exploitable UI bug allowing any amount to be paid when you get a fastpay pop up. Any vendor that does not check the paid value will hence give away items at 1L$. Research should likely give numerous ways of exploiting this so the only safe solution is to get the vendor fixed.

IMPORTANT: Warn all your friends that are using vendors listed below! If you know of a vendor not listed here using the fastpay method and want it checked, IM me. If you're a coder for a vendor or anything else receiving payments: ALWAYS check the amount paid versus the amount you wanted to receive.

Vendors that are vulnerable:
* JEVN
- versions: I assume all prior to 3.4 that support Fastpay, I'll add specific version numbers if there's a list
- solution: Upgrade to 3.4 (verified)

* Vendor (v2.1 fastpay)(freeplus) by Caligari Designs
- versions: see name
- solution: Remove the vendor (I have not found a new version yet)

Note: keep the drama out of this thread, we've got one with a few pages already for that. Try to keep it useful in here.

Vendors that are reported to be safe:
Drifting Thoughts
Wolfhaven
NDE
SVN

Just to let people know, all current Drifting Thoughts vendors check the amount paid, even when using llSetPayPrice(), and are therefore not vulnerable to this expoloit. I can't remember of the top of my head if previous versions didn't check, but I think they do. Current grid problems prevent me from double checking the scripts, but I will edit this post as soon as I can. I do know however that the current versions (v2.2) check the amount paid.

I am happy to report that ALL current Wolfhaven vendor systems including the WHV2 and WSVS networked systems ALL check the amount paid even with fastpay.

All NDE Vendors have always and will always continue to check price paid, regardless of the use of fastpay buttons. The same holds true for NDE rental boxes.

It's a simple quality control...I'm actually surprised to see that there were vendors that failed to check these prices...

That is exactly the truth, the error is not in the FastPay code, I have tested it myself and for the bug to be in the FastPay settings, an actual readable event would have to be brought up when the dialog came up etc.

The BUG is scripters who wrote the actual vendors not checking if the incoming amount matched the amount of the item currently displayed. When dealing with money in SL, and scripting too for that matter, you should never assume the end user will do the right thing. Whether out of mistake or maliciousness, something can and will go wrong.

(didnt use code view because its a small block, but this way it loses formatting)

amount is amount paid in, currItemPrice is the price for the item on the screen.

money(key id, integer amount)
{
if (amount == currItemPrice)
{
// Code to give the item etc etc
}
else
{
// Anything else you need here
}
}

I just wish more people understood, as I am actually seeing some people say now, the bug is with the scripter not checking if the amount paid equaled the amount for the item on the screen. I know what I said may be sort of paraphrased from what others have said about it, but it seemed like not many actually broke it down and explained the actual "problem."

Update as the asset server is running good enough to allow opening scripts. All Drifting Thoughts vendors check the price, and if the amount is greater than product price will give the product and return the difference in price. Only reason I didn't say for certain in the last post is I tested the vendor with not checking the price, but found the problem with changing products and went back to checking price, but wasn't 100% certain and I don't like saying things if I'm not positive.

The SVN quasi-networked vendor system released here on the boards also checks price paid. In fact, looking through the source code comments, it would seem that the original author actually had it in mind when programming it. It's possible that he's the one that originally reported it, or at least one of the early people who witnessed the problem in action.

i though this post was to indicate vendors that where NOT doing the check, not a reason for all the vendor makers to post "my vendor work dont worry" or i would have posted mine too -_-

greed

Well it does reassure people that are using those vendors so it doesn't exactly hurt. As long as it doesn't turn into drama it's fine. I wouldn't mind keeping a list of verified vendors.

The ones I make check - they're also the ones in use at ONE.

I've been performing spotchecks around SL on devices using fastpay.

Results:
- no broken vendors found yet except those already listed
- most other devices (e.g. gambling machines) are ok

My policy on information:
- Broken vendors -> notify creator if they are not yet aware
- Broken gambling machines -> notify owner

The reason I contact owners for gambling machines is the fact that you can drain them dry if it goes unnoticed too long hence they should know immediately. I've found some but the majority works fine and I've found no bugs in any gambling device that is widespread.

For vendors the biggest issue is the widespread use of JEVN. I've not tested all those I saw but I expect many are not upgraded.