10
ಕೆಲವು ದಿನಗಳ ಹಿಂದೆ ಆ ಸುದ್ದಿ ಬಿಡುಗಡೆಯಾಯಿತು ಲಿನಕ್ಸ್ ಕರ್ನಲ್‌ನಲ್ಲಿ ಎರಡು ದೋಷಗಳನ್ನು ಗುರುತಿಸಲಾಗಿದೆ ಅವುಗಳಲ್ಲಿ ಮೊದಲನೆಯದನ್ನು ಈಗಾಗಲೇ CVE-2022-0435 ಎಂದು ಪಟ್ಟಿ ಮಾಡಲಾಗಿದೆ ಮತ್ತು TIPC (ಪಾರದರ್ಶಕ ಇಂಟರ್-ಪ್ರೊಸೆಸ್ ಕಮ್ಯುನಿಕೇಷನ್) ನೆಟ್‌ವರ್ಕ್ ಪ್ರೋಟೋಕಾಲ್‌ನ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಒದಗಿಸುವ ಲಿನಕ್ಸ್ ಕರ್ನಲ್ ಮಾಡ್ಯೂಲ್‌ನಲ್ಲಿ ಕಂಡುಬಂದಿದೆ.
ಈ ದುರ್ಬಲತೆ ಕೋಡ್ ಅನ್ನು ಕರ್ನಲ್ ಮಟ್ಟದಲ್ಲಿ ರನ್ ಮಾಡಲು ಅನುಮತಿಸಬಹುದು ವಿಶೇಷವಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಿದ ನೆಟ್‌ವರ್ಕ್‌ಗೆ ಪ್ಯಾಕೆಟ್ ಕಳುಹಿಸುವ ಮೂಲಕ.
ಸಮಸ್ಯೆ tipc.ko ಕರ್ನಲ್ ಮಾಡ್ಯೂಲ್ ಲೋಡ್ ಆಗಿರುವ ಸಿಸ್ಟಂಗಳ ಮೇಲೆ ಮಾತ್ರ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ ಮತ್ತು TIPC ಸ್ಟಾಕ್‌ನೊಂದಿಗೆ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿದೆ, ಇದನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಕ್ಲಸ್ಟರ್‌ಗಳಲ್ಲಿ ಬಳಸಲಾಗುತ್ತದೆ ಮತ್ತು ವಿಶೇಷವಲ್ಲದ ಲಿನಕ್ಸ್ ವಿತರಣೆಗಳಲ್ಲಿ ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಸಕ್ರಿಯಗೊಳಿಸಲಾಗುವುದಿಲ್ಲ.
ದುರ್ಬಲತೆ ಇದು ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಸಂಸ್ಕರಿಸುವಾಗ ಉಂಟಾಗುವ ಸ್ಟಾಕ್ ಓವರ್‌ಫ್ಲೋನಿಂದ ಉಂಟಾಗುತ್ತದೆ, 64 ಅನ್ನು ಮೀರಿದ ಡೊಮೇನ್‌ನ ಸದಸ್ಯರ ನೋಡ್‌ಗಳ ಸಂಖ್ಯೆಯೊಂದಿಗೆ ಕ್ಷೇತ್ರದ ಮೌಲ್ಯ.
tipc.ko ಮಾಡ್ಯೂಲ್‌ನಲ್ಲಿ ನೋಡ್‌ಗಳ ನಿಯತಾಂಕಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು, ಒಂದು ಶ್ರೇಣಿಯು "u32 ಸದಸ್ಯರು[64 ]" ಅನ್ನು ಹೊಂದಿಸುತ್ತದೆ, ಆದರೆ ಪ್ಯಾಕೇಜ್‌ನಲ್ಲಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ಪ್ರಕ್ರಿಯೆಯ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ. ನೋಡ್ ಸಂಖ್ಯೆಯು "member_cnt" ಮೌಲ್ಯವನ್ನು ಪರಿಶೀಲಿಸುವುದಿಲ್ಲ, ಇದು ಕೆಳಗಿನ ಮೆಮೊರಿ ಪ್ರದೇಶದಲ್ಲಿ ಡೇಟಾದ ನಿಯಂತ್ರಿತ ಓವರ್‌ರೈಟಿಂಗ್‌ಗಾಗಿ 64 ಕ್ಕಿಂತ ಹೆಚ್ಚಿನ ಮೌಲ್ಯಗಳನ್ನು ಬಳಸಲು ಅನುಮತಿಸುತ್ತದೆ. "dom_bef" ರಚನೆಯ ನಂತರದ ಸ್ಟಾಕ್.
TIPC ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಮೂಲತಃ ಎರಿಕ್ಸನ್ ಅಭಿವೃದ್ಧಿಪಡಿಸಿದೆ, ಇದು ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಪ್ರಕ್ರಿಯೆಗಳ ನಡುವೆ ಸಂವಹನವನ್ನು ಸಂಘಟಿಸಲು ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ ಮತ್ತು ಮುಖ್ಯವಾಗಿ ಕ್ಲಸ್ಟರ್‌ನ ನೋಡ್‌ಗಳಲ್ಲಿ ಸಕ್ರಿಯಗೊಳಿಸಲಾಗುತ್ತದೆ. TIPC ಎತರ್ನೆಟ್ ಮತ್ತು UDP ಎರಡರಲ್ಲೂ ಕೆಲಸ ಮಾಡಬಹುದು (ನೆಟ್‌ವರ್ಕ್ ಪೋರ್ಟ್ 6118).
ಈಥರ್ನೆಟ್ನಲ್ಲಿ ಕೆಲಸ ಮಾಡುವಾಗ, ಸ್ಥಳೀಯ ನೆಟ್ವರ್ಕ್ನಿಂದ ದಾಳಿಯನ್ನು ಮಾಡಬಹುದು, ಮತ್ತು UDP ಅನ್ನು ಬಳಸುವಾಗ, ಜಾಗತಿಕ ನೆಟ್ವರ್ಕ್ನಿಂದ, ಪೋರ್ಟ್ ಅನ್ನು ಫೈರ್ವಾಲ್ನಿಂದ ಮುಚ್ಚದಿದ್ದರೆ. ಹೋಸ್ಟ್‌ನಲ್ಲಿ ಸವಲತ್ತುಗಳಿಲ್ಲದೆ ಸ್ಥಳೀಯ ಬಳಕೆದಾರರಿಂದ ದಾಳಿಯನ್ನು ಸಹ ನಡೆಸಬಹುದು. TIPC ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಲು, ನೀವು tipc.ko ಕರ್ನಲ್ ಮಾಡ್ಯೂಲ್ ಅನ್ನು ಲೋಡ್ ಮಾಡಬೇಕು ಮತ್ತು ನೆಟ್‌ಲಿಂಕ್ ಅಥವಾ ಟಿಪಿಸಿ ಉಪಯುಕ್ತತೆಯನ್ನು ಬಳಸಿಕೊಂಡು ನೆಟ್‌ವರ್ಕ್ ಇಂಟರ್‌ಫೇಸ್‌ಗೆ ಬೈಂಡಿಂಗ್ ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಬೇಕು.
ಎಂದು ಉಲ್ಲೇಖಿಸಲಾಗಿದೆ ಕರ್ನಲ್ ಅನ್ನು "CONFIG_FORTIFY_SRC=y" ಮೋಡ್‌ನಲ್ಲಿ ನಿರ್ಮಿಸುವಾಗ (RHEL ನಲ್ಲಿ ಬಳಸಲಾಗಿದೆ), ಇದು memcpy() ಕಾರ್ಯಕ್ಕೆ ಹೆಚ್ಚುವರಿ ಪರಿಮಿತಿಗಳ ಪರಿಶೀಲನೆಗಳನ್ನು ಸೇರಿಸುತ್ತದೆ, ಕಾರ್ಯಾಚರಣೆಯು ತುರ್ತು ನಿಲುಗಡೆಗೆ ಸೀಮಿತವಾಗಿದೆ (ಕರ್ನಲ್ "ಕರ್ನಲ್ ಪ್ಯಾನಿಕ್" ಸ್ಥಿತಿಗೆ ಹೋಗುತ್ತದೆ).
ಹೆಚ್ಚುವರಿ ಪರಿಶೀಲನೆಗಳಿಲ್ಲದೆ ಇದನ್ನು ನಡೆಸಿದರೆ ಮತ್ತು ಸ್ಟಾಕ್ ಅನ್ನು ರಕ್ಷಿಸಲು ಬಳಸಲಾಗುವ ಕ್ಯಾನರಿ ಫ್ಲ್ಯಾಗ್‌ಗಳ ಬಗ್ಗೆ ಮಾಹಿತಿಯು ಸೋರಿಕೆಯಾಗುತ್ತದೆ, ಕರ್ನಲ್ ಹಕ್ಕುಗಳೊಂದಿಗೆ ಕೋಡ್ ಅನ್ನು ರಿಮೋಟ್ ಆಗಿ ಕಾರ್ಯಗತಗೊಳಿಸಲು ಸಮಸ್ಯೆಯನ್ನು ಬಳಸಬಹುದು. ಸಮಸ್ಯೆಯನ್ನು ಗುರುತಿಸಿದ ಸಂಶೋಧಕರು ಶೋಷಣೆ ತಂತ್ರವು ಕ್ಷುಲ್ಲಕವಾಗಿದೆ ಮತ್ತು ವಿತರಣೆಗಳಲ್ಲಿನ ದುರ್ಬಲತೆಯನ್ನು ವ್ಯಾಪಕವಾಗಿ ತೆಗೆದುಹಾಕಿದ ನಂತರ ಬಹಿರಂಗಪಡಿಸಲಾಗುವುದು ಎಂದು ಹೇಳುತ್ತಾರೆ.
ದುರ್ಬಲತೆಯನ್ನು ಉಂಟುಮಾಡಿದ ದೋಷವನ್ನು ಜೂನ್ 15, 2016 ರಂದು ಪರಿಚಯಿಸಲಾಯಿತು ಮತ್ತು Linux 4.8 ಕರ್ನಲ್‌ನ ಭಾಗವಾಯಿತು. ದುರ್ಬಲತೆ ಕರ್ನಲ್ ಆವೃತ್ತಿಗಳಲ್ಲಿ ಸ್ಥಿರವಾಗಿದೆ ಲಿನಕ್ಸ್ 5.16.9, 5.15.23, 5.10.100, 5.4.179, 4.19.229, 4.14.266 ಮತ್ತು 4.9.301.
ಮತ್ತೊಂದು ದುರ್ಬಲತೆ ಇದು Linux ಕರ್ನಲ್‌ನಲ್ಲಿ ಕಂಡುಬಂದಿದೆ rlimit ನಿರ್ಬಂಧಗಳನ್ನು ನಿರ್ವಹಿಸಲು ಕೋಡ್‌ನಲ್ಲಿ CVE-2022-24122 ಆಗಿದೆ ವಿಭಿನ್ನ ಬಳಕೆದಾರ ನೇಮ್‌ಸ್ಪೇಸ್‌ಗಳಲ್ಲಿ.
2021 ರ ಬೇಸಿಗೆಯಲ್ಲಿ ಸೇರಿಸಲಾದ ಬದಲಾವಣೆಯಲ್ಲಿ ದೋಷವನ್ನು ಪರಿಚಯಿಸಲಾಗಿದೆ, "ucounts" ರಚನೆಯನ್ನು ಬಳಸಲು ಕೆಲವು RLIMIT ಕೌಂಟರ್‌ಗಳ ಅನುಷ್ಠಾನವನ್ನು ಚಲಿಸುತ್ತದೆ. RLIMIT ಗಾಗಿ ರಚಿಸಲಾದ "ucounts" ಆಬ್ಜೆಕ್ಟ್‌ಗಳು ಅವುಗಳಿಗೆ ಸಂಬಂಧಿಸಿದ ನೇಮ್‌ಸ್ಪೇಸ್ ಅನ್ನು ತೆಗೆದುಹಾಕುವ ಮೂಲಕ (ಬಳಕೆಯ ನಂತರ-ಮುಕ್ತ) ಮೆಮೊರಿಯನ್ನು ಮುಕ್ತಗೊಳಿಸಿದ ನಂತರ ಬಳಸುವುದನ್ನು ಮುಂದುವರೆಸಿದವು, ಇದು ಅವರ ಕೋಡ್‌ನ ಕರ್ನಲ್-ಮಟ್ಟದ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯನ್ನು ಸಾಧಿಸಲು ಸಾಧ್ಯವಾಗಿಸಿತು.
ಉಬುಂಟು ಮತ್ತು ಫೆಡೋರಾದಲ್ಲಿ ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಸಕ್ರಿಯಗೊಳಿಸಲಾದ ಬಳಕೆದಾರ ಐಡೆಂಟಿಫೈಯರ್ ನೇಮ್‌ಸ್ಪೇಸ್‌ಗೆ (ಸವಲತ್ತುರಹಿತ ಬಳಕೆದಾರ ನೇಮ್‌ಸ್ಪೇಸ್) ವ್ಯವಸ್ಥೆಯು ಅನಪೇಕ್ಷಿತ ಪ್ರವೇಶವನ್ನು ಹೊಂದಿದ್ದರೆ, ಆದರೆ ಡೆಬಿಯನ್ ಮತ್ತು ಆರ್‌ಹೆಚ್‌ಇಎಲ್‌ನಲ್ಲಿ ಸಕ್ರಿಯಗೊಳಿಸದಿದ್ದಲ್ಲಿ ಮಾತ್ರ ಸವಲತ್ತು ಇಲ್ಲದ ಬಳಕೆದಾರರಿಂದ ದುರ್ಬಲತೆಯ ದುರ್ಬಳಕೆ ಸಾಧ್ಯ.
ದುರ್ಬಲತೆಯನ್ನು ನಿರ್ಬಂಧಿಸಲು ಪರಿಹಾರವಾಗಿ, ನೀವು ಬಳಕೆದಾರರ ನೇಮ್‌ಸ್ಪೇಸ್‌ಗೆ ಅನಪೇಕ್ಷಿತ ಪ್ರವೇಶವನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಬಹುದು:
sysctl -w kernel.unprivileged_userns_clone=0
ಸಮಸ್ಯೆ ಲಿನಕ್ಸ್ ಕರ್ನಲ್ 5.14 ರಿಂದಲೂ ಇದೆ ಮತ್ತು 5.16.5 ಮತ್ತು 5.15.19 ನವೀಕರಣಗಳಲ್ಲಿ ಸರಿಪಡಿಸಲಾಗುವುದು. Debian, Ubuntu, SUSE/openSUSE ಮತ್ತು RHEL ನ ಸ್ಥಿರ ಶಾಖೆಗಳು ಸಮಸ್ಯೆಯಿಂದ ಪ್ರಭಾವಿತವಾಗಿಲ್ಲ, ಆದರೆ ಹೊಸ Fedora ಮತ್ತು Arch Linux ಕರ್ನಲ್‌ಗಳಲ್ಲಿ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತವೆ.