unexpected mdsstop behavior

[Sven_Glock]

Hi community,

last week I accidently stopped a critical R80.40 mdm environment.
Why accidently? I wanted the see if there are possible options or switches I can use with the command "mdsstop".

So I tryed: "mdsstop --help"

This is what I normally do when looking for help context under linux.

The problem:
mdsstop does not have the options "--help" and "/?", but it does not respond like it does for example cpinfo: "invalid option".
It just executed the command without any flags which means "mdsstop" so my mdm went down...

BTW: The correct option to see the help is "-h". It's the same with mdsstat and mdsstart.

I opened a service request to find out if this is expected behavior.
Check Point answered that this is not a linux command, so I can not expect same options.
If I want to know possible options I should have a look in the admin guide and if needed anyways I should open an RFE.

I would say ignoring invalid options is not a good implementation of options.
Minimum should be a feedback of "invalid option" without executing the command.
Optimum would be "invalid option" without executing the command and showing possible options.
For A+ "--help", "-h" and "/?" should show help context, invalid options should respond with "invalid option" followed by a list of possible options.

So how do you guys think about the options of mdsstop/mdsstart/mdsstat?
Is it worth opening an RFE?

Thanks for your opinion.

Cheers
Sven

[Bob_Zimmerman]

That is absolutely a bug, not an RFE. If you pass any unexpected parameters to a destructive command, it shouldn't just proceed as if nothing was wrong. It's as bad as how snapshots used to ask for confirmation before telling you that if you confirmed, they would stop all your services. Or to use a more current example, it's as bad as naming a load viewer 'cptop'.

This lack of input validation on destructive commands is what led to an AWS operator bringing down S3 for all of US-East-1.

For a security vendor to suggest that input validation of all things is an RFE is laughable.

[PhoneBoy]

Input validation implies that input is processed.
In this case, it appears mdsstop does not process any input at all.
cpstop, however, appears to:

[Expert@R81.10mgmt:0]# cpstop --help
To stop CheckPoint's products, please run cpstop

Not having MDM installed anywhere, I'm not sure if mdsstop is a bash script or a binary like cpstop is.
Regardless, it seems like a simple thing to fix.
@Tomer_Noy 

[Sven_Glock]

Here are some examples from my lab running R80.40 JHF 114:

mdsstop -checkmatesmdsstop --helpmdsstop /?mdsstop -h

[Danny]

I recommend to report things like these to Check Point: https://www.checkpoint.com/security-issue/

[Sven_Glock]

Today I got the feedback from R&D that there will be a fix in the next JHF release!