new plugin for Network Extreme MLXe switches with SFP port#6201
new plugin for Network Extreme MLXe switches with SFP port#6201rmorandell-pgum wants to merge 10 commits into
Conversation
rmorandell-pgum
requested review from
jean-christophe81,
lucie-tirand and
sechkem
and removed request for
a team
![aikido-pr-checks[bot]](https://avatars.githubusercontent.com/in/898896?s=60&v=4){kind=small}
|
|
||
| =item B<--unknown-status> | ||
|
|
||
| Define the conditions to match for the status to be WARNING (default: '%{temp_status} =~ /unknown/ || %{tx_power_status} =~ /unknown/ || %{rx_power_status} =~ /unknown/ || %{bias_status} =~ /unknown/'). |
There was a problem hiding this comment.
The --unknown-status help says it sets WARNING, but this option is used for UNKNOWN logic. This contradiction can lead to incorrect status configuration and unexpected alerting behavior.
| Define the conditions to match for the status to be WARNING (default: '%{temp_status} =~ /unknown/ || %{tx_power_status} =~ /unknown/ || %{rx_power_status} =~ /unknown/ || %{bias_status} =~ /unknown/'). | |
| Define the conditions to match for the status to be UNKNOWN (default: '%{temp_status} =~ /unknown/ || %{tx_power_status} =~ /unknown/ || %{rx_power_status} =~ /unknown/ || %{bias_status} =~ /unknown/'). |
Details
✨ AI Reasoning
The mode defines a dedicated unknown status condition, but the corresponding help text states that this option sets WARNING. That mismatch creates contradictory behavior expectations and can cause users to configure thresholds incorrectly because the documented outcome cannot match what the code actually does.
Reply @AikidoSec feedback: [FEEDBACK] to get better review comments in the future.
Reply @AikidoSec ignore: [REASON] to ignore this issue.
More info
| if (defined($self->{option_results}->{display_transform_src})) { | ||
| $self->{option_results}->{display_transform_dst} = '' if (!defined($self->{option_results}->{display_transform_dst})); | ||
|
|
||
| $self->{safe}->reval("\$assign_var =~ s{$self->{option_results}->{display_transform_src}}{$self->{option_results}->{display_transform_dst}}", |
There was a problem hiding this comment.
User-supplied display_transform_src/display_transform_dst are interpolated into a string passed to Safe->reval, enabling code injection via get_display_value; avoid evaluating constructed code from untrusted input.
Details
✨ AI Reasoning
The change adds dynamic evaluation of a string built from option_results values using Safe->reval. The code assigns the display value to a shared variable and then calls reval with a string that contains the user-provided display_transform_src and display_transform_dst interpolated directly into a substitution operation. This allows an attacker controlling those options to inject Perl code or craft malicious patterns that could alter execution when reval processes the constructed string. Although Safe is used, constructing code from untrusted input and passing it to an evaluator is inherently risky and can lead to code-injection or unexpected behavior. The problematic flow: user-supplied option_results -> interpolated into code string -> passed to reval for evaluation.
🔧 How do I fix it?
Use parameterized queries with placeholders, array-based command execution (no shell interpretation), or properly escaped arguments using vetted libraries. Avoid dynamic queries/commands built with user input concatenation.
Reply @AikidoSec feedback: [FEEDBACK] to get better review comments in the future.
Reply @AikidoSec ignore: [REASON] to ignore this issue.
More info
2 participants
Community contributors
Description
Since there is already an “extreme->snmp” entry, I moved the existing one to “extreme->standard->snmp”
Modes Available:
Type of change
How this pull request can be tested ?
FOUNDRY-SN-SWITCH-GROUP-MIB
FOUNDRY-SN-AGENT-MIB
Extreme Networks MLXe.7z.txt
extreme-mlxe.snmpwalk.txt.7z.txt
sfp-ports => snIfOpticalLaneMonitoringTable
hardware => snChassis
temp => snAgentTempTable
memory => snAgSystemDRAMUtil
cpu => snAgentCpuUtilTable
Checklist