A potential risk in the fc-llm-api can be used to escalate permission.

[zolaer9527]

Hello! I found a potential risk in the fc-llm-api when I deployed it in the Alibaba Cloud Serverless Application Center. The service of the application has the role of excessive permission. A malicious can leverage the permissions of "ram:PassRole" for * resources and "fc:*" for * resources to escalate permission.

Details Analysis
After the application was deployed, it created a service named fc-llm. This service has three functions that are llm-model-download, llm-server, and llm-client. They all inherit the role of fc-llm service. This role has the AliyunFCFullAccess policy and the policy has the permissions of "ram:PassRole" for * resources and "fc:*" for * resources. The two actions have no restriction on resources while using * directly. So a malicious user who controls this function can escalate privilege by leveraging these two permissions to pass an existing RAM role to a new function. This would give a user access to the privileges associated with any Function Compute service role that exists in the account, which could range from no privilege escalation to full administrator access to the account.

Attack Scenario
Assuming such an attack scenario, in a company, there are two employees Bob and Alice, and the company has an Alibaba Cloud account. The two employees are two RAM users in the account. Bob's RAM user only has the relevant permissions for Function Compute, while Alice's RAM user has administrator permissions. Alice has created the fc-llm-api application through the serverless application center in the account. In that way, Bob can use the permissions related to Function Compute to obtain the AccessKeyID, AccessKeySecret, and SecurityToken of the role used by the service in the fc-llm-api, thereby causing permission escalation.

Mitigation Discussion

1. Use RAM paths or a naming convention to grant principal access to pass RAM roles using wildcards (*) in a portion of the role ARN.
2. Protect specific RAM paths with an SCP. You can also protect specific RAM paths by using an SCP. Or you can craft a policy allowing only a specific naming convention or RAM path to pass a role in a specific path.
3. The resources of the permission "ram:PassRole" and the "fc:*"should be restricted by using the specified resource name.

Question

1. Is it a real issue in the fc-llm-api?
2. If it's a real issue, can any of my suggestions be used to solve this problem?
3. If my suggestions could be used to solve this problem, could you give me a CVE number to award my discovery?

By the way, I have sent an email to [email protected] according to your CONTRIBUTING.md, but it said the email doesn't exist. So I have to raise an issue to report this issue to you. I apologize for any inconvenience caused to you.

[zolaer9527]

Hello, are there any updates?

[zxypro1]

@lowkeyrd Please check. Also, for Alibaba Cloud issues, its better to report via aliyun.com website.