ოფიციალურ MCP Python SDK-ში ხარვეზი მავნე სერვერს OAuth-ის მონაცემების მოპარვის საშუალებას აძლევს

რა მოხდა

MCP Python SDK-ის ოფიციალურ პაკეტში უსაფრთხოების ხარვეზი დადგინდა: მავნე MCP სერვერს შეუძლია აპლიკაცია მოატყუოს და მიიღოს ის OAuth-ის მონაცემები, რომლითაც ნამდვილ სერვისში შესვლა ხდება. შემქმნელებმა პრობლემა 28 სექტემბერს გამოქვეყნებულ უსაფრთხოების ბიულეტენში აღწერეს. MCP (Model Context Protocol) ღია სტანდარტია AI აპლიკაციების გარე ხელსაწყოებთან დასაკავშირებლად, და ეს პაკეტი მისი ოფიციალური Python SDK-ია.

დაზარალებულ ვერსიებში კლიენტი MCP სერვერს ეკითხებოდა, სად იყო მისი ავტორიზაციის სერვისი, და SDK ამ პასუხს ყოველთვის არ ამოწმებდა. მავნე სერვერს შეეძლო კლიენტი თავისივე სერვისზე გადაეტანა, და კლიენტი client secret-ს, ავტორიზაციის კოდსა და PKCE-ის გასაღებს ნამდვილი პროვაიდერის ნაცვლად თავდამსხმელს უგზავნიდა.

რატომ არის საშიში

PKCE-ის გასაღები ერთჯერადი მნიშვნელობაა, რომელიც მოპარული კოდის ხელახლა გამოყენებას უნდა აღკვეთოს, ამიტომ მისი გადაცემა ამ დაცვასაც აუქმებს. მოპარული მონაცემებით თავდამსხმელს ნამდვილი სერვისიდან ნამდვილი access token-ის მოთხოვნა შეუძლია.

კომპანია Cycode, რომელმაც ხარვეზი შეატყობინა, სრული გაცვლა ტესტში აჩვენა და განაცხადა, რომ მიღებულ ტოკენს იგივე უფლებები აქვს, რაც აპლიკაციას ჰქონდა მინიჭებული. client secret გრძელვადიანია, ამიტომ შეცვლამდე მუშაობას განაგრძობს. ხარვეზს მაღალი, 7,5 შეფასება აქვს ადამიანის გარეშე მომუშავე ორი პროვაიდერისთვის, ხოლო ინტერაქტიურისთვის 6,5. 29 სექტემბრის მდგომარეობით CVE მინიჭებული არ იყო.

ვინ არის დაზარალებული

აპლიკაცია დაზარალებულია, თუ SDK-ს MCP კლიენტად იყენებს HTTP-ზე OAuthClientProvider, ClientCredentialsOAuthProvider, PrivateKeyJWTOAuthProvider ან მოძველებული 1.x RFC7523OAuthClientProvider პროვაიდერით და შეუძლია დაუკავშირდეს სერვერს, რომელსაც სრულად არ აკონტროლებს, სანამ ნამდვილი სერვისის მონაცემები აქვს. SDK-ით აწყობილი MCP სერვერები, ლოკალური stdio კლიენტები და საკუთარი ტოკენების მქონე კლიენტები დაზარალებული არ არიან.

1.x ხაზზე დაზარალებულია 1.9.1-დან 1.29.1-მდე ვერსია და გამოსწორებულია 1.30.0-ში, 2.x ხაზზე კი 2.0.0-დან 2.1.1-მდე, გამოსწორებულია 2.2.0-ში.

რა უნდა გაკეთდეს

განაახლეთ 1.30.0 ან 2.2.0 ვერსიამდე. გამოსწორებულ ვერსიებში კლიენტი ჯერ თავად ადგენს, რომელ ავტორიზაციის სერვისს ელოდება, და უარყოფს ყველას, რომელიც სხვას მიუთითებს.

აპლიკაციებმა ClientCredentialsOAuthProvider-ით ან PrivateKeyJWTOAuthProvider-ით დამატებით უნდა გადასცენ issuer= და მიუთითონ, რომელ სერვისს ეკუთვნის ეს მონაცემები; მხოლოდ განახლება ამის გარეშე არაფერს ცვლის. მოძველებულ RFC7523OAuthClientProvider-ს issuer= პარამეტრი არ აქვს და ის სხვა ორიდან ერთით უნდა შეიცვალოს. ძველ ვერსიებზე მხოლოდ სანდო MCP სერვერებს დაუკავშირდით.

issuer-ის შემოწმება 1.30.0 და 2.2.0 ვერსიების release notes-ში 7 სექტემბერს გამოჩნდა, უსაფრთხოების გამოსწორების ნაცვლად ქცევის ცვლილებებში. ბიულეტენი 28 სექტემბერს გამოქვეყნდა, იმავე დღეს, რაც Cycode-მა საკუთარი ანალიზი. ხარვეზის გამოყენებით თავდასხმა არ დაფიქსირებულა.