Fast Pay "Exploit"

Then please explain it to us, because all I can see in this thread is people making the assumption that usinga fastpay amount always results in the correct amount being paid, which is user error and not a bug. If you take shortcuts when coding a vendor, don't complain when they are "exploited". It's not hard to add a if (ammount_paid==item_price) line to your money handler.

If there's some bug in llSetPayPrice or other that could cause vendors to break we need to know about it. Why should JEVN get the opportunity to fix vendors but nobody else?

Hopefully Linden Lab will explain the bug WHEN it is fixed.


If I explain the bug before it is fixed it would sort of be like shouting out the combination to the local bank's safe in the middle of the market place BEFORE they changed it, wouldnt it ?

(Not a very clever idea)

I've been trying everything to get llSetPayPrice to do anything even remotely odd.

Multiple avs - multiple quickpay boxes, randomly used, some cancelled, others used - simultanious (or near so) payments... llFrand got a workout, changing "expected" prices.

Fact is, however much the av pays, is how much registers in the money() event. There is no mysterious discrepancy between what's payed and what registeres. There is no bug with llSetPayPrice.

Someone phone NASA and tell them they are wasting their time

I have jumped up and down, used ladders on the top of buildings , even attempted to grow wings - I cant reach the moon.

Therefore its not possible. (please excuse the sarcasm - after you read Torley Lindens reply in Linden Questions )

I just logged in and checked - Yeps - still there.

You yourself said it was fairly widely known on another thread. It just so happens that I don't hang around with people who tell me exploits for vendors, that's all. Maybe I should, in order that I and all the other people not blessed with this magical knowledge can take steps to avoid it.

If it's fairly widely known, as you said, your silence on the subject fails to make any sense.

If checking the amount passed in the money() event is sufficient - I suspect this is not a bug as much as it is a missed expectation.

This 'fast pay' bug isn't a bug at all, it's just flawed transaction verification on the scripters part.

Believe what you want to believe - wish I hadn't bothered now - next time I shalln't.

If it is a real bug, you're being irresponsible by not making this "common knowlege" available to those who can act to prevent its exploitation.

This is positively my last post on the subject.

How many people out there are going to thank me if I post

ON AN OPEN PUBLIC FORUM


Perform the following

Step (A)
Step (b)
Step (c)

Then touch piece (d)

You can bypass


Do you really think that only scripters are reading this ?

Every low life in SL will rush to log in to find Vendors that are still at risk - Then who are you going to blame ?

ME


So I am dammed if I do and dammed if I don't.

So from now on - my stand on the subject is

It's Linden's bug - let them deal with it - I want no further part in it.

See, there's the rub... if it's common knowlege amongst said low-life, then it makes no difference if other low-lifes are reading it here.

Your defense is claptrap. If you've information that could be used to protect folks, it needs dissemination. Period.

Well ask a linden then.

So, the problem isn't poor coding relying on the vendor not checking the amount in the money event. But the workaround is... check the amount paid in the money event.

Is this thread just some elaborate viral marketing for JEVN? "JEVN vendors have been fixed and are not vulnerable to a bug that could affect any other vendor you use! But no-one in the world can reproduce the bug outside JEVN labs!"

Adriana, no worries, no one will blame you. It just not a general bug in SL, you should of IMed the JEVN scripters, not LL :\

Nep:
You said "Is this thread just some elaborate viral marketing for JEVN?"...

No, I started this thread because I want to know the truth. As a scripter I need to know if there is a real exploit, or if it was just a bug in JEVN. The JEVN people keep claiming it was an exploit. If that is the case then everyone needs to know about it so that we can put in measures to prevent it.

I'm a mostly happy JEVN user, that's all. Yeah I lost some lindens due to this bug, but that's not a huge deal. I understand that stuff happens. I'm not going to say I never forgot to make an obvious confirmation check in a program I wrote, we all screw up sometimes.

But if it is a bug in LSL/SL then we should know about it. Obviously the people exploiting it know about it, so this secrecy serves no one except the "bad guys", who can continue to scam until Linden Labs reverts the behavior.

And if it's just that the fastpay box isn't modal now, and it used to be, for christ's sakes just say so! It's not a huge deal.

It is not a bug in LSL.

llSetPayPrice behaves exactly as described in the documentation: it alters the amounts of money displayed when the Pay dialog is invoked on the object. That's all it does.

The transaction of buying an item from a vendor isn't atomic, and has never been. It's always been theoretically possible for a griefer to hide out near a vendor, wait for someone to buy something - and the moment before they click "OK" on the pay box, change the selected item on the vendor so they buy the wrong item. Of course, they would be guessing about the exact timing - but it's possible!

I've been bitten by this kind of thing often enough I now draw out Message Sequence Charts for items in SL and it's helped me out a lot on several occasions Anyone know if an LSL to ProMeLa compiler would be possible?

An example of a well designed vender is the Lusk avatar vendor. The vendor locks to a single user when it is in use, and unlocks after a certain period of no interaction. It keeps multiple users from mucking with it. The current behavior doesn't have any bugs in it.

If LL were to change the behavior, they would do so in one of two ways.

1. close pay boxes on change.
   
2. refresh pay boxes on change.
   

Even with these I still would verify the amount of money payed. It's irresponsible not to. Anyone who doesn't, deserves all the drama they get for thier incompetence.

Adriana you're trolling.
As per forum guidlines, don't.

I am still a noob scripter and have been working on my own multi-item vendor recently. I am a programmer in RL as well, so it is in my nature to RTFM and try to understand everything there is to know about how the elements of what I am working with actually work. I also run through as many usage scenarios in my head (and on paper, too ) as I can to catch as many potential "gotchas" in the design phase of a product.

That said, when I considered how llSetPayPrice worked, plus considering how just using Pay... on the pie menu worked, I also considered the problem of multiple users as well as single users changing the vendor to another item while paying the price on the first. It seemed painfully obvious that a check in the money() event to compare the price paid with the sale price of the current item was a necessary thing. However, even that was a little too simplistic to deal with the overall problem. I considered using sessions, but without checking with the user somehow, there still could be an issue with casual browsing with one or more friends.

The scenario I was considering was where two people were out together shopping, both of them browsing the same multi-item vendor, both at various times clicking the product selection buttons, and then both buying the same item when done browsing.

The other scenario involved a buyer and a malicious griefer, who would surreptitiously change the item selection while the buyer was in the process of paying the vendor, causing the buyer to purchase the wrong product.

In either case, the only real way to solve the problem with script as it stands today is to include some kind of dialog IF the product last selected by the buyer is not the currently selected product on the vendor. That requires keeping sessions, which would include avatar key, item ID, and a session ID. If the product being paid for is not the one selected by the buyer, then you pop the dialog with two choices: currently selected product, and last selected product. The only down side to that is the hideously small amount of text on the buttons, so you would have to use something that explained the situation in the text of the dialog, with the full names of the products, then use some kind of index on the buttons (like "A" and "B", for example) This would also necessitate keeping a second item ID as part of the state, lest someone change the vendor again while the user was deciding with this dialog. Also, a price comparison should be made to reduce the likelihood of needing the dialog. If one product or the other is not the price that was paid, then it is safe to assume the user didn't want to buy that item. There still is a possibility that the vendor can be switched again during the processing of this logic (ie, where the buyer stopped switching the vendor, had a friend switch it to something they both wanted to buy, but the friend or even another patron switched it before the payment went through). In such a case, it would be expected to tell the user to use the Ignore button in the dialog if they wanted neither item. Again, this hinges on all the items in question being the same price, but since that is a fairly common situation, it has to be handled. As another said, you could just use unique prices for every item, which would solve the problem, but unique prices for small, cheap items might be a little difficult at times.

Anyway, based on the rest of this thread, it seems there are a couple of issues. One is that a particular vendor does not do what most scripters would consider an "obvious" check to make sure that the price paid matches the one for the currently selected item. That's unfortunate, and it is good that it will be corrected. However, even as of last night, there are a LOT of those vendors out there, and I suspect that quite a few of them will not be updated before some serious fainancial damage could be done. Regardless of how this is spun, if it is true, it is definitely a coding error on the part of the scripter, and NOT a bug in LSL. A weakness in design, maybe, but I get the impression that the money handling part of LSL is fairly basic, and the notion of multi-item vendors was not considered in its design.

There seems to be a second, unrelated issue being brought up about a bug in LSL with llSetPayPrice. If so, full disclosure prior to a fix may not be a good idea. I have my doubts as to the claims of it being "common knowledge". It certainly isn't common enough to have reached my noob ears. Then again, I am not a low-life, out seeking to rip people off. However, full disclosure of the bug only encourages more folks to "try it", so it probably is in the best interests of all involved to keep it on the QT for now. As with anything security-related, it is a balancing act between people's right to be informed so they can protect themselves, and minimizing the damage until the problem is fixed. While some of us here might want desperately to know so we can jump right in and fix our own stuff, I would say that the majority of folks would remain ignorant of the problem (ie, not check the forums, or be slothful in updating all of their vendors), and would get hit hard by a wave of "kiddie fraud" that normally comes from full disclosure of security holes. I would hope that LL would make efforts to contact the vendor sellers and developers and at least give them an immediate workaround so they can help their customers out now. Trouble is knowing who they are and getting them the information. I'd like to be included in that group, but since I don't have any vendors out there (yet), there is no risk in not telling me, unless the fix is long in coming.

As for a more permanent fix, I think the way it should be handled is to do a "surety" system, where the script sets not only the price, but the item name, short description, and an asset key (or inventory name) at the same time. Then, when the user selects "pay", the client pops up a dialog box with all the info, minus the product ID code, and prompts the user to accept or cancel the transaction based on the info it provides. If the user accepts, the item is delivered to them. Pretty much how "Buy..." works now, showing the object contents, but instead of the user buying the vendor, it instead buys a script-specified object. I think that also would solve a lot of issues with lag and the money event not firing issue as described in the Wiki. An optional parameter could also allow for email or IM notification by the system.

Just my L$2.

As an addendum to something I forgot to mention..

I also considered the idea of "locking" a vendor to a patron while he/she browsed. However, I rejected that idea, as it can be easily griefed, even unintentionally, causing a denial of service situation. Locking is good when you have no intention to allow casual access to something, but with shopping, casual is the name of the game. I know that if I browse by some shop which has patron-locked vendors that haven't timed out yet, I would just pass on by and spend money elsewhere. It's really not a good solution for this kind of situation, in my mind.

Locking is an issue, Lusk solves this by having 5 identical venders.

Aye, that's the naturally way to solve it, as no two people would try use a normal vending machine at the same time, and there is usually more than one in high-traffic areas. Still, the potential for grief makes it unattractive to me. I have little doubt that it works well enough to justify its use, I would just like to seek out a more elegant solution that has little to no chance of inconveniencing my customers.

Plus, not everyone has the prim resources (or space, for that matter) available in their shops to have multiple identical vendors.

To do that I think you'd need a money_start(integer x) event or some-such, which would return how many people currently have pay dialogues open to the vendor, and whenever someone opens the pay dialog it would lock for X seconds or until they pay-up.
My vendors using locking as well, fairly intelligently but it still has much the same problems.

But if someone is sitting 'griefing' the locked vendor then it should be fairly easy to see who it is and report them for being an ass.

One of the other people on this list came up with half a good solution IMO, at least for a number of situations.

Set all your items at different prices. Check the price using a fast pay button and blank the others. If the vendor gets "moved" it will have a different expected price, return the money and say why - and don't deliver of course.

It's easy to script. It's easy to avoid if you're shopping with your friend - the first time it happens you tell your friend and then tell them you're going to buy x so they don't do it again. If someone's griefing the system you can look round and try to see who's screwing around and AR them...

I strongly suspect I'll stay with some small margin for error because there will be a few duplicate prices (clothes sellers seem to like similar prices for their ranges though so it's probably not a total fix although many clothes vendors use single box per item vendors in their main stores now).

This would be a potential problem for things that should be sold at the same price (avatars, different shirt designs, etc.), however, if you should charge (say) L$200 for an item (and there's 4 of them), Fast Pay it for 200, 201, 202, and 203, and then pay back the amount that the person "overpaid" in order to do the amount check.